1. If checkAndRefreshInvalidObject(original, parentCacheKey, descriptor) is called, where is the actual refresh happening if isConsideredInvalid(..) returns true (which is the case for the scenario being described)?
   
2. Should the first parameter of checkAndRefreshInvalidObject(original, parentCacheKey, descriptor) have been updated already after the call to checkAndRefreshInvalidObject()?
   
3. If not, how are the refreshed attributes merged into the variable workingClone in org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.class.cloneAndRegisterObject(..), because after checkAndRefreshInvalidObject(..), the method keeps working the the possibly stale "original" or rather creates a "workingClone" of it?
   
4. I checked the members "object" on unitOfWorkCacheKey & parentCacheKey in cloneAndRegisterObject(..) and they are both null, should the refresh of checkAndRefreshInvalidObject(..) be visible in these members instead?
   
5. The overall logic of cloneAndRegisterObject(..) puzzles me a bit: Even if the results of checkAndRefeshInvalidObject(..) end up in the UOW session, the method keeps working with the old value "original" and does not retrieve it somehow out of the session afterwards. Therefore I suppose, in either UnitOfWorkImpl.populateAndRegisterObject(..) or among the interactions between ObjectLevelReadQuery and ObjectBuilder should be some registration in UOW session happening. Still, even if this were the case, how are these changes incorporated into workingCopy at the end of cloneAndRegisterObject(..)?
   

While investigating an issue regarding stale data within optimistic locks (eventually causing an OptimisticLockException) in a setup with two nodes and JMS synchronized caching, I started to debug into EclipseLink and to my understanding found the place where the problem arises but unfortunately I do not quite understand its reason.

In org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject the object is checked for validity with checkAndRefreshInvalidObject(). The query which is issued eventually after this.executeQuery(query) in checkAndRefreshInvalidObject() returns the correct lock code, but when the control flow returns to cloneAndRegisterObject(), the object "original" still has the old values which are incorporated into "workingClone" a few lines later.

I was a bit surprised to see, that checkAndRefreshObject() has no return value and the object "original" is not updated directly or rather the result of the query within it is simply discarded. I further assume, there should be some behind-the-scenes updating initiated by "query.refreshIdentityMapResult()" in checkAndRefreshObject(), correct?

Environment: EclipseLink 2.6.0, Oracle-DB, Two Payara nodes with a shared cache synchronized by ActiveMQ.
Additional remarks: The table in question uses SINGLE_TABLE inheritance, and the child has a column OPT_LOCK annotated with @Version.

• There is an explicit call to flush within the transaction, which according to https://www.eclipse.org/eclipselink/documentation/2.6/concepts/cache003.htm marked it as dirty effectively disabling the second level cache for the remaining transaction.
  
• The cache coordination is set to INVALIDATE_CHANGED_OBJECTS
  

My questions would be:

1. If checkAndRefreshInvalidObject(original, parentCacheKey, descriptor) is called, where is the actual refresh happening if isConsideredInvalid(..) returns true (which is the case for the scenario being described)?
   
2. Should the first parameter of checkAndRefreshInvalidObject(original, parentCacheKey, descriptor) have been updated already after the call to checkAndRefreshInvalidObject()?
   
3. If not, how are the refreshed attributes merged into the variable workingClone in org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.class.cloneAndRegisterObject(..), because after checkAndRefreshInvalidObject(..), the method keeps working the the possibly stale "original" or rather creates a "workingClone" of it?
   
4. I checked the members "object" on unitOfWorkCacheKey & parentCacheKey in cloneAndRegisterObject(..) and they are both null, should the refresh of checkAndRefreshInvalidObject(..) be visible in these members instead?
   
5. The overall logic of cloneAndRegisterObject(..) puzzles me a bit: Even if the results of checkAndRefeshInvalidObject(..) end up in the UOW session, the method keeps working with the old value "original" and does not retrieve it somehow out of the session afterwards. Therefore I suppose, in either UnitOfWorkImpl.populateAndRegisterObject(..) or among the interactions between ObjectLevelReadQuery and ObjectBuilder should be some registration in UOW session happening. Still, even if this were the case, how are these changes incorporated into workingCopy at the end of cloneAndRegisterObject(..)?
   

1. In org.eclipse.persistence.internal.descriptors.ObjectBuilder (see above)
   
2. Yes
   
3. Redundant by the previous answer
   
4. I think it should be visible on parentCacheKey but not on unitOfWorkCacheKey, which may be part of the root cause of the issue.
   
5. Redundant by previous answers.
   

ObjectBuilder:965: cacheKey = session.retrieveCacheKey(primaryKey, concreteDescriptor, joinManager, query);

ObjectBuilder:2250: workingClone = buildNewInstance()

workingClone = unitOfWork.getParentIdentityMapSession(query).retrieveCacheKey(primaryKey, descriptor, joinManager, query).getObject()