Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » CacheCoordination with synchronization type INVALIDATE_CHANGED_OBJECTS issues
CacheCoordination with synchronization type INVALIDATE_CHANGED_OBJECTS issues [message #1730447] Mon, 25 April 2016 22:09 Go to next message
Leny Tan is currently offline Leny TanFriend
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)



Re: CacheCoordination with synchronization type INVALIDATE_CHANGED_OBJECTS issues [message #1730530 is a reply to message #1730447] Tue, 26 April 2016 14:04 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1272
Registered: July 2009
Senior Member
I believe this is by design, not a bug but you might elaborate on how you are obtaining the company instance to be sure.

Any references to Employee will remain as is until the employee instance is refreshed. With invalidation, the employee will be automatically refreshed when it is read in from the cache. Unfortunately you are accessing the Company instance which is already in the cache and had its list of employees fetched, so there is no read required.

This depends on how the Company instances was read in. I am not sure what the behavior should be when the instance is read from the shared cache, in which case each employee needs to be cloned into the current UOW/EntityManager. If that is what is happening, you might try the latest EclipseLink version and file a bug if it is still returning a stale Employee instance.

It is recommended to increment the version number in root entities when parts of the graph may change so that remote instances can pick up the change or prevent merging in changes on the graph when dependent parts may have changed out from under it.

Re: CacheCoordination with synchronization type INVALIDATE_CHANGED_OBJECTS issues [message #1731069 is a reply to message #1730530] Mon, 02 May 2016 16:49 Go to previous message
Leny Tan is currently offline Leny TanFriend
Messages: 6
Registered: September 2015
Junior Member
Hi, Chris

Thanks for your response. So, I tried to upgrade to version 2.6.2 and run our automation test and it's still have the same behavior as 2.2.0.

Regarding your comment about "This depends on how the company instances was read in...". Can you elaborate more?
Is this mean " once an object is registered or read via an UoW, that the cloning process would recognize that the cached object is invalid and hence, will 'do the right thing' and refresh the cache?"




Previous Topic:IndirectList executes a contains() check on add(). Why?
Next Topic:Uni-directional OneToMany problems with JPA2.0 -> JPA2.1 migration
Goto Forum:
  


Current Time: Tue Nov 21 01:06:32 GMT 2017

Powered by FUDForum. Page generated in 0.02026 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software