On Fri, 2006-10-27 at 15:40 +0100, Manik Surtani wrote: > First off, thanks to all who attended, it was a very useful session. > Please let me know if I have missed anything or if there are any > inaccuracies. > 1) Detail of Hibernate usage of JBoss Cache > > - Notion mismatch between a Cache put() - which is a write - and a > Hibernate put() - which is a read from a DB. A Hibernate update() is > effectively a write. > - This notion mismatch causes unnecessary locking in JBoss Cache > when doing a Cache put(). > - Hibernate maintains 3 types of caches: for caching entities, > caching queries and caching collections > - Most other cache providers used are flat and non-replicated, > assumes each region is isolated > - Replicated EHCache not tested with Hibernate. > - Assumes other cache providers don't handle concurrency, Hibernate > wraps these in a ConcurrencyStrategy and handles locking separately. > - Hence to need to differentiate between a Hibernate put() and > update() as these both translate to a cache.put(). > - JBoss Cache could be used this way, with IsolationLevel.NONE > - This is a waste though, as it prevents using JBoss Cache to it's > full potential. > - A good temp. solution for now. One thing I mentioned on the call is that ReadWriteStrategy requires not just a distributed store for objects, but also distributed locking. It needs functions to synchronously lock/unlock a node across the cluster - a concept which is pretty alien to the current JBoss Cache code. (?) - Owen