Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 347496

Summary:	@OptimisticLocking(cascade = true) does not cascade @PrivateOwned Collection Deletes
Product:	z_Archived	Reporter:	Ecmel Ercan <ecmel.ercan>
Component:	Eclipselink	Assignee:	Nobody - feel free to take it <nobody>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P2	CC:	ruebe356, tom.ware
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Ecmel Ercan

2011-05-27 14:13:36 EDT

Build Identifier: 2.2.0.v20110202-r8913

I have an entity marked with @OptimisticLocking(cascade = true) and using version locking policy.

The entity has a bi-directional @OneToMany field marked with @PrivateOwned.

Inserts to the field's collection and updates of collection items correctly increases the entity's version count but only DELETES do NOT.

In order to workaround, I do:

ClassDescriptor.getOptimisticLockingPolicy().setLockOnChangeMode(LockOnChange.ALL);

but I am not sure if this is the correct way.



Reproducible: Always

Steps to Reproduce:
1. Create a versioned entity and mark with @OptimisticLocking(cascade = true)
2. Create a @PrivateOwned @OneToMany collection field.
3. Add to the collection
4. Entity's version field will increment.
5. Modify fields of the added item.
6. Entity's version field will increment.
7. Delete the item.
8. Entity's version field will NOT BE CHANGED.

Comment 1 Tom Ware

2011-06-09 10:07:21 EDT

Setting target and priority.  See the following page for the meanings of these fields:

http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines

Community: Please vote for this bug if it is important to you.  Votes are one of the main criteria we use to determine which bugs to fix next.

Comment 2 thorsten kruse

2018-12-14 04:31:23 EST

I get an OptimisticLockException which could raise because of the same reason described here. I have an an Object A and an 1:n relation to Object B. The relation is annotated @PrivateOwned. Steps to reproduce the exception are:
1) Get a UnitOfWork
2) Read an A
3a) Get a nested UnitOfWork
3b) Register A at nested UnitOfWork
3c) Deleted all Bs from A
3d) Create new Bs for A
3e) commmit nested UnitOfWork
4) repeat Steps 3)
5) commit UnitOfWork
Not only the version number is unset, even the primary key and all(!) field of B are unset. The composite primary key is set programmatically, not by database sequence. It looks like the object B causeing the exception is created whithin step 3 as a incomplete clone and gets into the UnitOfWork change-set. The exception does not come when step 4) is omitted.

org.eclipse.persistence.exceptions.OptimisticLockException: 
Exception Description: An attempt was made to delete the object [B], but it has no version number in the identity map. 
It may not have been read before the delete was attempted. 
Class> B Primary Key> [[0, 0]: 961]
	at org.eclipse.persistence.exceptions.OptimisticLockException.noVersionNumberWhenDeleting(OptimisticLockException.java:108) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.descriptors.VersionLockingPolicy.addLockValuesToTranslationRow(VersionLockingPolicy.java:110) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.queries.DeleteObjectQuery.prepareForExecution(DeleteObjectQuery.java:368) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:896) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.queries.DeleteObjectQuery.executeInUnitOfWorkObjectLevelModifyQuery(DeleteObjectQuery.java:119) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2896) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1804) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1786) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1737) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.CommitManager.deleteAllObjects(CommitManager.java:336) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.CommitManager.deleteAllObjects(CommitManager.java:290) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1444) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1531) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitRootUnitOfWork(UnitOfWorkImpl.java:1351) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commit(UnitOfWorkImpl.java:1113) ~[eclipselink.jar:2.5.2.v20140319-9ad6abd]

Comment 3 thorsten kruse

2019-06-27 07:51:15 EDT

I think the cause of my described behaviour is https://bugs.eclipse.org/bugs/show_bug.cgi?id=548627

Comment 4 Eclipse Webmaster

2022-06-09 10:24:30 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink