[jbosscache-dev] Minutes from JBossCache and Hibernate conf call.

[Manik Surtani]

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 at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani