Community
Participate
Working Groups
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.
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.
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]
I think the cause of my described behaviour is https://bugs.eclipse.org/bugs/show_bug.cgi?id=548627
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
