Re: [eclipselink-users] INVALIDATE_CHANGED_OBJECTS does not invalidate r

[mwolochuk <mwolochuk@xxxxxxxxx>]

We are reading the object through the Session with a readObject query (not
using JPA) - for example:

Expression expression = new
ExpressionBuilder().exprBuilder.get("id").equal(id);
Employee employee = (Employee) session.readObject(Employee.class,
expression)

Now, say an Employee has a Department, and employee1 belongs to department1.
We start with the precondition that both employee1 and department1 are in
the session cache on both server1 and server2, and cache synchronization is
set to INVALIDATE_CHANGED_OBJECTS.

Now we modify department1.name on server1. Next, on server2, we get
employee1 with the above query, then get the department:

department1 = employee1.getDepartment();

We find that department1.name is the old name - it is has not been changed.
I think it is because the invalidation is on department1, not employee1.
Since we are getting department1 through the object graph rather than from
the cache, it is still the old value. Ideally, employee1 would also have
been invalidated since it has a reference to department1.



James Sutherland wrote:
> 
> By default any invalid object will be refreshed when accessed through a
> UnitOfWork (or JPA EntityManager).
> 
> If you are using JPA the UnitOfWork is always used, unless you execute a
> read-only query or the class is read-only.  How are you reading the
> objects?
> 
> You can configure the refresh to not occur using the descriptor's
> ClassInvalidationPolicy.setShouldRefreshInvalidObjectsInUnitOfWork(false).
> 
> 
> 
> 
> mwolochuk wrote:
>> 
>> We recently changed our cache synchronization type from
>> SEND_NEW_OBJECTS_WITH_CHANGES to  INVALIDATE_CHANGED_OBJECTS. Upon
>> testing, we discovered that changes made through server1 were not
>> reflected on server2. After further testing, we found that when another
>> object has a direct reference to the invalidated object on the remote
>> server, and you access the invalidated object through that reference, you
>> get the old invalid instance.
>> 
>> For example:
>> 
>> 1. Assume this object graph: a->b (object a refers to object b).
>> 
>> 2. Assume object b has a field "someField" with a value "oldValue"
>> 
>> 3. Assume both a and b are in the cache on both servers.
>> 
>> 4. On server1, you do this: a.getB().setSomeField("newValue"), then
>> commit the transaction
>> 
>> 5. Now on server2, you get a reference to "a" from EclipseLink: a =
>> findById(A.class, A_ID)
>> 
>> 6. Finally, you access object "b" through object "a":
>> a.getB().getSomeField()
>> 
>> The value you get in step 6 is "oldValue" instead of "newValue".
>> 
>> EclipseLink invalidates the instance of "b" in server2 cache, but not the
>> instance of "a". So if we access "b" through "a", we get the old invalid
>> object.
>> 
>> Is this expected behavior? Based on this discussion 
>> http://forums.oracle.com/forums/thread.jspa?threadID=982925&tstart=298
>> http://forums.oracle.com/forums/thread.jspa?threadID=982925&tstart=298 ,
>> it seems it is the expected behavior. I did not see anything in
>> EclipseLink documentation or javadocs describing this behavior.
>> 
>> To me this makes the setting INVALIDATE_CHANGED_OBJECTS not very useful
>> since we often access objects through the object graph. Am I missing
>> something?
>> 
> 
> 

-- 
View this message in context: http://old.nabble.com/INVALIDATE_CHANGED_OBJECTS-does-not-invalidate-related-objects-tp29432889p29523290.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.