Does EHCache require put() in order for changes to instance to reflect (XA)?

I've started working with EHCache as a transactional cache (XAResource) in a JTA UserTransaction and I'm seeing something which is a bit strange, at least in my mind, and I'd like to understand whether my "seeing" is wrong or my understanding.

The following code will return false

ut = getUserTransaction();
ut.begin();
MyClass a = myChache.get(key).getValue();
a.changeSomeInnerReferrence(newRefference);
ut.commit();
ut = getUserTransa开发者_如何转开发ction();
ut.begin();
MyClass b = myChache.get(key).getValue();
ut.commit();
return a.equals(b);

Let's assume MyClass has a member of the type MyOtherClass and that changeSomeInnerReferrence changes the reference from the current value to the parameter; Also assume that equals takes that member into consideration.

I noticed that unless I add myChache.put(key,a) before the ut.commit() the above code will return false.

Why is that? Is this the general behavior of caches? I would think that changing an inner reference would propagate into the cache once commit is called.

Thanks,

Ittai

Bit of a preface here, I haven't used EHCache in the context of JTA. It is possible it does something clever within a user transaction, but I kinda doubt it.

The general rule is that the element returned by cache.get(key) is by value. Changes to it aren't necessarily reflected in the underlying cache. The reasoning behind it becomes pretty clear if you imagine not having an in-memory store at all, but only a disk store. The disk store requires serializing the cache entries, so a put/get pair of operations will return you a different Java instance. Further, in such a situation it's not clear when any changes to the instance returned by cache.get() would/should get written back to disk. Using a put() makes that clear.

In the end, the thing you get from get() is your responsibility. You tell EHCache to take over by saying put().