Community
Participate
Working Groups
There is some non-determinism in ComplexMultipleUnitOfWorkTest that causes the following intermittent issue when run in the ProtectedUnitOfWorkTestModel Exception Description: The object [Address: 1450 Acme Cr., suite 4, Sudbury, ONT, Canada], of class [class org.eclipse.persistence.testing.models.employee.domain.Address], with identity hashcode (System.identityHashCode()) [1,679,402,192], is not from this UnitOfWork object space, but the parent session's. The object was never registered in this UnitOfWork, but read from the parent session and related to an object registered in the UnitOfWork. Ensure that you are correctly registering your objects. If you are still having problems, you can use the UnitOfWork.validateObjectSpace() method to help debug where the error occurred. For more information, see the manual or FAQ. Local Exception Stack: Exception [EclipseLink-6004] (Eclipse Persistence Services - 2.2.0.v20110203-r8920): org.eclipse.persistence.exceptions.QueryException Exception Description: The object [Address: 1450 Acme Cr., suite 4, Sudbury, ONT, Canada], of class [class org.eclipse.persistence.testing.models.employee.domain.Address], with identity hashcode (System.identityHashCode()) [1,679,402,192], is not from this UnitOfWork object space, but the parent session's. The object was never registered in this UnitOfWork, but read from the parent session and related to an object registered in the UnitOfWork. Ensure that you are correctly registering your objects. If you are still having problems, you can use the UnitOfWork.validateObjectSpace() method to at org.eclipse.persistence.exceptions.QueryException.backupCloneIsOriginalFromParent(QueryException.java:272) The issue is in the changeObject method: manager.addManagedEmployee((Employee)unitOfWork.readObject(Employee.class)); This line can retrieve any employee. If it retrieves the previously modified Employee with firstName=Marcus and the Address listed in the exception, we see the problem because proper clean-up has not occurted in the previous method.
Created attachment 188324 [details] Proposed fix
Comment on attachment 188324 [details] Proposed fix Setting test case fix to be obsolete. We should change the test case to always fail and fix the failure.
Created attachment 188526 [details] ComplexMultipleUnitOfWorkTest modified to give the error and eliminate extra actions
There appears to be an issue in protected descriptors that cause this issue. A stripped down version of the test case is included. It does the following 1. Read EmployeeJudy who was created earlier in the same session (different UnitOfWork) 2. Read EmployeeMarcus who was previously read in the same session and had his address changed 3. Make EmployeeMarcus the manager of EmployeeJudy 4. commit This bug may be related to Bug 336134, but initial investigation shows it is not exactly the same bug. It might be a good idea to fix these two bugs together.
The issue can be found in the ObjectReferenceMapping.createCloneValueHolder(). This code assumes that if we are building from rows in a UOW and the ValueHolder that is being cloned is triggered then we should just use the value in the valueholder as it was built by this UOW anyway. The issue comes when using Protected Entities where we may be building from a ROW in a UOW but the cache can also be accessed for cacheable mappings.
The solution is to let the cloning code know that the value was retrieved from the cache.
Created attachment 189322 [details] Initial proposed patch This attachment adds a Boolean "holder" that is passed to valueFromRow to allow it to notify the caller if the cache was used. In the case where the cache is used the call to cloneAttribute is updated for cache based cloning and not build directly from rows. TransformationMapping needs more refactoring to have similar processing paths so another patch is forthcoming.
Created attachment 189746 [details] Proposed Patch This patch includes updates to the transformation mapping and adds a regression test.
Created attachment 189747 [details] Proposed Patch Changed root for patch file
Created attachment 189817 [details] Final Patch
Changes checked into 2.2.1 and 2.3
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink