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

[Manik Surtani]

Sorry about jumping in on this so late, just back from vacation and  
still ploughing through backlog.

1)  2.0.0.GA will not be out for a while.  Planning a long CR run and  
coinciding GA with JGroups 2.5, circa early June.
2)  When you say separate caches, you would need separate cache  
instances if they were to run with separate configurations.  (To  
reduce the network resource overhead, they could use a single  
multiplexed JGroups channel).  Region based caches is a long way off  
(3.0.0 timeframe?)
3)  JBoss Cache 2.0.0.GA will only be supported under Java 5.  A  
retroweaved 1.4 compat binary *could* be built but for now this will  
*not* be supported. [1].  As such, I think there will always be a  
need for JBoss Cache 2.0.0 and 1.4.0 support in Hibernate - unless  
you foresee Hibernate usage with JDK 1.4 as an outlying minority that  
can be ignored here.
4)  Steve, re: the TM issue, how could we delegate this to a  
strategy?  At the moment we register Synchronizations directly with  
the TM.  Are you suggesting that Hibernate injects the strategy into  
a JBC instance and the JBC instance registers the Synchronization  
there instead of the TM?  If this is so, does a strategy implement  
any standard interface so as not to couple JBC and Hibernate?

Cheers,
Manik

[1] http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHabaneroJava1.4






On 10 Apr 2007, at 22:23, Brian Stansberry wrote:

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

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani