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

[Steve Ebersole]

Oh, just saw 2.0 is still in BETA...  How close are y'all to GA?

Steve Ebersole wrote:
> 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
>
>