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. Cheers, Manik 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. 2) Use of a putForExternalRead(): - Successor to the deprecated putFailFast() and Options.FAIL_SILENTLY - TX suspension - Minimal error messages and exceptions - Consider Owen's solution to only write if the node does not exist - otherwise fail silently. - Steve and Manik to investigate the correctness of this approach. - Deprecate/remove Option.FAIL_SILENTLY && putFailFast() - Could be introduced in JBoss Cache 1.5.0 && 2.0.0? 3) Optimistic locking and data versioning issues with the Query Cache - Invalidation and data versioning does not make sense for Query Cache and Collections Cache - Data needs to be available on all cluster instances - Versions only exist for entities, not for queries. - Solution: Run multiple caches on a multiplexed JGroups channel. - Each cache instance configured differently to meet the needs of caching queries, collections or entities. - Hack this into Hibernate 3.2.x TreeCacheProvider _ Better architectural abstractions between the different caches in 3.3.x? 4) Invalidation issues and edge cases (JBCACHE-806) - Description: V2 put into CacheA. CacheB has V1, gets the invalidation msg, and V1 is evicted. Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache? This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache. - Solution: Use INV_SYNC and if a remote eviction fails with a data version mismatch on a remote node, propagate the exception back to the caller. - JBCACHE-806, target for 1.4.x series. *** Actions * Put unit tests to cover these new features in JBoss Cache (MS) * Put together comprehensive integration tests to exercise these, try and get these tests into automated release testing with QA for JBoss Cache and Hibernate (SE) * Investigate JBoss Cache in IsolationLevel.NONE with ReadWrite Concurrency Strategy (SE) * Investigate putForExternalRead() (MS) * Investigate multiplexed JBoss Caches in TreeCacheProvider (SE) * Fix JBCACHE-806 (MS) Cheers, -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani