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

[Max Rydahl Andersen]

> 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".

Cool.

> 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?

Long-term:
In Hibernate - use seperate caches which you have done for 3.3
In JBoss Cache - as it stands now you would have to use differnt  
jbosscache configurations.
In older versions of JBC you would need different treecache.xml; but that  
has been simplified
in later JBC's AFAIK - Manik/galder ? Depending on this and wether  
optimistic locking is a global
or node level-and-down setting users might need some less or more complex  
"writing jbosscache config files
for hibernate" examples ;)

Short-term:
Write a cacheprovider that would use different jbosscaches for each "type"  
of cache.
Not sure if that still makes sense.

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

I recall these as being Bryan 2 things:

1) setting up JBC/Cacheprovider so it would use the correct classloader  
when loading data from the cache.

2) doing some "mutations"/magic-lookup of the cache region names to know  
which classloader to use
(this might just me having nightmares, so need Bryan to certify ;) If it's  
true we would
need to look into the practicallity of that solution.

> 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?

I don't recall more progress on that topic.

/max

> 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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com