[hibernate-dev] Re: JBoss Cache and Hibernate Integration

Steve Ebersole steve at hibernate.org
Fri Apr 6 12:13:20 EDT 2007


So I started breaking out 3.3 as a separate code base on the Hibernate 
svn trunk.  The first thing done was this org.hibernate.cache.Cache 
splitting.  So at this point we now have the ability to be completely 
free in how we cache entity-data versus collection-data versus 
query-data versus timestamps-data within the same "second level cache".  
But now looking back at #1, I am no longer certain of the conclusions; 
and to me the wiki did not make it clear to me what the "long term" 
solution was supposed to be (nor really what the "short term" solution 
is/was either).  Anyone remember the specific conclusions with regards 
to this point?

Re: #4 : what exactly are these differences?  Now is the time to merge 
it back...

Re: #5 : what about the other solution I proposed where instead of 
registering synchs directly with the TC/TM, you instead delegate it to a 
strategy which can route the request back through Hibernate; Hibernate 
can then manage ordering the callbacks?

Re: #6 : I'm actually in favor of just moving to the new (2.0) API; 
easier from a management perspective. 
> Ok, so my notes from the call, based on issues from the wiki
>
>
> 1.  Multiple caches will probably only formally make it in the next 
> major Hibernate release - 3.3.
>
> 2 Notes on putForExternalRead() functionality, in addition to the 
> solution presented on the wiki:
> - PFER only goes through if node does not exist; no-op otherwise
> - Force asynchronous mode for replication or invalidation to prevent 
> any blocking
> - 0ms lock timeout to prevent any blocking here either.  If this 
> fails, PFER is a no-op
> - no to separate thread necessary, since we will be operating with a 
> 0ms timeout, async replication and a no-op if the node exists.  The 
> only real chance of any blocking here is JGroups FC which is 
> considered small enough a case.
>
> 3.  Since JBC 1.4.1.SP1, write locks are not acquired on parents when 
> adding or removing children, to be more accurate to repeatable read 
> semantics.  WLs can still be acquired on parents if enabled in the 
> configuration (see "LockParentForChildInsertRemove" in 
> http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1.SP2/TreeCache/en/html/configuration.html, 
> which defaults to false).  As such, this contention should no longer 
> be a problem.
>
> 4.  Brian implemented for EJB3 clustering in AS 4.2, will make it's 
> way back into HIbernate in the 3.3 timeframe?
>
> 5.  Do nothing for now since the urgency is removed.  Only fails on 
> old versions of JBoss TS.  In future (JBC 2.1 timeframe) look at what 
> the microcontainer has to offer with synchronisation registrations.
>
> 6.  Coordination issue
>
> 7.  Galder to come back with more details here, but general consensus 
> is not to perform transparent retries.
>        
> Feel free to add stuff I may have missed or further thoughts.  Very 
> useful and productive call!
>
> Cheers,
> Manik




More information about the hibernate-dev mailing list