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

Bug 336357

Summary: ComplexMultipleUnitOfWorkTest fails intermittently on ProtectedSession
Product: z_Archived Reporter: Tom Ware <tom.ware>
Component: EclipselinkAssignee: Gordon Yorke <gordon.yorke>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: eclipselink.foundation-inbox, gordon.yorke
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Proposed fix
none
ComplexMultipleUnitOfWorkTest modified to give the error and eliminate extra actions
none
Initial proposed patch
none
Proposed Patch
none
Proposed Patch
none
Final Patch none

Description Tom Ware CLA 2011-02-04 10:09:11 EST
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.
Comment 1 Tom Ware CLA 2011-02-04 10:11:40 EST
Created attachment 188324 [details]
Proposed fix
Comment 2 Tom Ware CLA 2011-02-08 10:28:03 EST
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.
Comment 3 Tom Ware CLA 2011-02-08 10:29:46 EST
Created attachment 188526 [details]
ComplexMultipleUnitOfWorkTest modified to give the error and eliminate extra actions
Comment 4 Tom Ware CLA 2011-02-08 10:35:09 EST
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.
Comment 5 Gordon Yorke CLA 2011-02-18 13:51:34 EST
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.
Comment 6 Gordon Yorke CLA 2011-02-18 13:52:04 EST
The solution is to let the cloning code know that the value was retrieved from the cache.
Comment 7 Gordon Yorke CLA 2011-02-18 16:01:13 EST
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.
Comment 8 Gordon Yorke CLA 2011-02-24 15:57:00 EST
Created attachment 189746 [details]
Proposed Patch

This patch includes updates to the transformation mapping and adds a regression test.
Comment 9 Gordon Yorke CLA 2011-02-24 16:06:05 EST
Created attachment 189747 [details]
Proposed Patch

Changed root for patch file
Comment 10 Gordon Yorke CLA 2011-02-25 10:46:30 EST
Created attachment 189817 [details]
Final Patch
Comment 11 Gordon Yorke CLA 2011-02-28 10:11:06 EST
Changes checked into 2.2.1 and 2.3
Comment 12 Eclipse Webmaster CLA 2022-06-09 10:08:54 EDT
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
Comment 13 Eclipse Webmaster CLA 2022-06-09 10:16:55 EDT
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink