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

[Max Rydahl Andersen]

>>> 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.
>>
>
> Manik can better comment on plans for having separate configurations  
> (e.g. optimistic vs pessimistic, invalidation vs replication) for  
> different regions of the cache. But, I know it's not a soonish thing.

ok.

> That means if you want different behavior for the different "types" of  
> caches you need separate caches. If the JGroups multiplexer is  
> available, that's not too bad, as the caches can share a channel. If we  
> think it through well, they can likely share an overall config file,  
> with the different "types" just overriding a couple properties that are  
> relevant.

sounds good. Could you provide an good default fallback setup for  
hibernate to run with ?

> If the JGroups multiplexer isn't available then having a separate cache  
> for each "type" is a royal pain, since you have multiple channels that  
> need to have unique ports, etc.  And we need to assume that the  
> multiplexer won't be available in any non-JDK5 env, since the earliest  
> JG release where it's reliable is 2.5.

So I guess we just won't have good jbosscache integration before 2.5;  
similar that
it won't work good before Hibernate 3.3. Is that a problem ?

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

> The issue here is that if you send a message to replicate type Foo, on  
> the remote node the thread coming up from JGroups that handles the  
> message needs access to the Foo class in order to deserialize Foo and  
> put it in the cache. Determining the correct classloader to use is a  
> problem if the cache is shared between multiple deployments.  There's a  
> standard JBC API to handle this use case, as discussed at  
> http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1/TreeCache/en/html/treecache_marshaller.html.

I understand that part.

> The fix I did was just to 1) have the org.hibernate.cache.Cache impl  
> make use of this API and

Got it.

> 2) prevent replication of the org.hibernate.cache.StandardQueryCache  
> region, since that region could be shared between multiple deployments  
> and hence there's no 'correct' classloader.

eh - ok, sounds bad.

Isn't it better to just use hibernate.cache.region_prefix to disambiguate  
the regions per sessionfactory ?

I don't think querycache region is the only one that would have problems  
if you are using the
same physical cache for multiple sessionfactories. e.g. if a  
org.company.model.Customer exists in both you would have troubles
with the entity cache.

> If we move to a mode where we have one cache (or set of caches) per  
> deployment, then this kind of stuff becomes unnecessary.  But, again,  
> that requires the JGroups multiplexer.

Today you should not use the same cache across deployment; that's a big  
nono.

The separation of caches has more to do with having different semantics  
with respect
to replication, locking and put/remove operations.

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

Don't forget this one - manik ? :)

/max

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



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