Eclipse Community Forums: EclipseLink » CacheCoordination with synchronization type INVALIDATE_CHANGED

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 18:09

Eclipse User

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 10:04

Eclipse User

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 12:49

Eclipse User

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:	Support for dynamic SQL from Expression API in predicates
Next Topic:	Entity automatically getting Detached and failing on insert for integrity constrain

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 15 22:25:59 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter