I think that Read Committed isolation level is not obliged to present you with up-to-date committed data - the only fact is that it can, but application must not rely on that. It's lower isolation level. Nevertheless, I think that lower isolation level should mean better performance. I would be strongly against imposing any additional overhead that could slow it down. I should give it some test, but if it currently does not offer any advantage against RR, I don't see any reason for this to exist.
Regarding the bug: Thanks a lot for pointing this out, I should adapt the testsuite to use different object types as values (if I understand the scenario correctly). Radim On 09/19/2013 12:03 AM, William Burns wrote: > I was recently refactoring code dealing with isolation levels and > found how ReadCommitted is implemented and I have a few concerns I > wanted to bring up. > > ReadCommitted read operations work by storing a reference to the value > from the data store in its caller's context. Thus whenever another > transaction is committed that updates the data store value any context > that has that reference now sees the latest committed value. This > works well for Local and Replicated caches since all data stores are > updated with the latest value upon completion of the transaction. > However Distributed caches only the owners see the update in their > data store and thus any non owner will still have the old value they > previously read before the commit occurred. > > This seems quite inconsistent that Distributed caches run in a mix of > Repeatable Read/Read Committed depending on what node and what key you > are using. > > To operate properly we could track requests similar to how it works > for L1 so we can tell non owners to clear out their context values for > values they read remotely that they haven't updated (since Read > Committed writes should return the same written value). That seems > like quite a bit of additional overhead though. > > I am wondering is it worth it to try to keep Read Committed isolation > level though? It seems that Repeatable Read would be simpler and most > likely more performant as you wouldn't need all the additional remote > calls to get it to work properly. Or is it okay that we have > different isolation levels for some keys on some nodes? This could be > quite confusing if a user was using a local and remote transaction and > a transaction may not see the other's committed changes when they > expect to. > > What do you guys think? > > - Will > > P.S. > > I also found a bug with Read Committed for all caches where if you do > a write that changes the underlying InternalCacheEntry to a new type, > that reads won't see subsequent committed values. This is caused > because the underlying data is changed to a new reference and a read > would still be holding onto a reference of the old InternalCacheEntry. > This can happen when using the various overridden put methods for > example. We should have a good solution for it, but may not be > required if we find that Read Committed itself is flawed beyond > saving. > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev