CacheCoordination with synchronization type INVALIDATE_CHANGED_OBJECTS issues [message #1730447] |
Mon, 25 April 2016 22:09 |
Leny Tan Messages: 6 Registered: September 2015 |
Junior Member |
|
|
Hi,
We currently use EclipseLink version 2.2.0 with JMS cache coordination. Recently we switched to use synchronization type INVALIDATE_CHANGED_OBJECT instead of SEND_NEW_OBJECTS_WITH_CHANGES. Then, we notice that one of our automation tests is failing.
After further debugging, we think the issue related to how the object marked in the cache or IdentityMapAccessor as "invalidate_state". This boolean is in the wrapper of the parent object.
Any clues on this? Whether this is an existing bug? Or are we missing something?
To elaborate:
So, for example this is what happened in our test:
1. We have Company and Employee class descriptor. And Company has OneToMany relationship with Employee. Both company and employee locking mechanism is their own version
2. When we call updateEmployee made in app1, then the employee version is bumped and JMS message containing the change set with invalidate_state type sent.
3. Then, app2 is trying to getEmployee record. What happen is when we call getEmployee, if call made to get employee is using company.getEmployee (company has OneToMany relationship with employee), then the data is stale. Since it'll use employee object as part of Company object in the identityMapAccessor.
4. It'll be different if we call directly from the parent, i.e. Employee.getById (since this will look at Employee object in identityMapAccessor, in which invalidate_state is set for this object)
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03373 seconds