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

[Brian Stansberry]

Max Rydahl Andersen wrote:
> 
>> 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 ?
> 

You mean one with a multiplexer? Right now a multiplexer gets injected 
into the cache; JBC has no mechanism to create one itself.  Sounds like 
we'll need to deal with that.

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

Just that JG 2.5 requires JDK 5. AIUI, Hibernate 3.3 will support JDK 
1.4. JBC 2.0 will have a retroweaved version that works with JDK 1.4 and 
that should work fine with JGroups 2.4.x. So, you can make Hibenate 3.3 
+ JBC work on JDK 1.4, but the multiplexer stuff won't work well. 
Confusing.

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

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

Yes, this was a hack to allow EJB3 entity clustering to work when people 
didn't specify a region prefix. (See below for more on why that's an 
issue). I certainly wouldn't mind seeing this go away.

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

Sure.  IIRC, if you specify a region_prefix that becomes part of the 
region name passed to o.h.c.TreeCache, in which case the hack that 
prevents replication would be bypassed.

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

JBoss AS currently deploys a single JBC instance for use as a shared 
cache across EJB3 deployments. If you specify 
org.jboss.ejb3.entity.TreeCacheProviderHook, that's what you get unless 
you go out of your way to deploy a separate cache.  The design decisions 
that led to doing it that way predate me, but I assume its due to the 
hassle of deploying multiple JGroups channels.

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

I think he's teaching this week??


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com