On 8 Dec 2011, at 15:10, Paolo Romano wrote: I think yes. There is an overhead in maintaining versions (additional memory, larger payloads to RPCs since versions need to be propagated, etc). So in certain cases if the application can deal with last-commit-wins, not using versions is a valid use case. -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org

On Dec 9, 2011, at 4:51 PM, Manik Surtani wrote: The put call comes from Hibernate, so Hibernate needs to deal with it somehow, otherwise how is it gonna deal with read/write and nonstrict read/write cache concurrency modes? If we take the case of inserting an entity (as opposed to reading a entity from db and putting it in the cache), Hibernate provides with two callbacks: EntityRegionAccessStrategy.insert and EntityRegionAccessStrategy.afterInsert The first call happens within the Hibernate transaction, and the second after the Hibernate transaction has completed. If the cache is transactional, like Infinispan is now, it's at insert time that we do the cache.put call so we participate of the transaction…etc. If the cache is read/write or non-strict read/write, you do nothing at insert time cos the cache is not transactional. Instead, you do the work in afterInsert. If there's any exceptions at afterInsert, it doesn't really matter because the transaction is complete and even if the cache.put() didn't work, the entity can get loaded next time around via a PFER into the cache. With an entity update however, I don't see Hibernate doing anything if the equivalent afterUpdate() call throws an exception. It only seems to log it. This could lead to the cache containing stale data and being retrieved by mistake by another tx unless the cache is cleared upon a failure to in afterUpdate(). -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache