Hey Manik and all, We had a talk at Devoxx on AtomicMap and tx isolation but its back to fuzzyness to me. can you help me reclarify. Here is the scenario. In Tx1 Map map = (AtomicMap) cache.get( key1 ); Date updateDate = map.get("date"); updateDate.setTime( System.currentTimeMillis() ); #cp 1 map.put("date", updateDate); End of Tx1 In Tx2 Map map = (AtomicMap) cache.get( key1 ); Date updateDate = map.get("date"); #cp2 display(updateDate); End of Tx2 Provided Date is mutable and assuming Tx1 and Tx2 run in the same node. Could it be that Tx2 display the new value of updateDate before Tx1 is committed. Or are you guys copying on read mutable objects? Emmanuel

Hi Emmanuel. With RepeatableRead, tx2 won't see the update till tx1 commits because the update (map.put()) is held in a change list until the tx is committed, before it is applied to the underlying AtomicMap. (Remember, what you get is a proxy). Ah, I see your question though; assuming the reference to the date is the same. Hmm, in this case you may well see the change before tx1 commits, we don't explicitly clone or copy mutable objects. We assume objects in an atomic map are immutable. I suppose though we could add the ability to defensively copy mutable objects, but we'd need a way of knowing which are immutable, etc. Also, this would be more expensive, depending on the size of the atomic map.

On 3 Dec 2010, at 11:03, Emmanuel Bernard wrote: > > On 3 déc. 2010, at 11:13, Manik Surtani wrote: > >> Hi Emmanuel. >> >> With RepeatableRead, tx2 won't see the update till tx1 commits because the update (map.put()) is held in a change list until the tx is committed, before it is applied to the underlying AtomicMap. (Remember, what you get is a proxy). >> >> Ah, I see your question though; assuming the reference to the date is the same. Hmm, in this case you may well see the change before tx1 commits, we don't explicitly clone or copy mutable objects. We assume objects in an atomic map are immutable. I suppose though we could add the ability to defensively copy mutable objects, but we'd need a way of knowing which are immutable, etc. Also, this would be more expensive, depending on the size of the atomic map. > > Hibernate has all the knowledge (mutable vs immutable and deep copy strategy) to do this kind of copy when appropriate. So this is not 100% needed in Infinispan though I think that could be less disturbing for people if you guys eventually implement something like that. > > In any case a small doc entry would be nice :) +1 on the docs, for sure.