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

[Max Rydahl Andersen]

FYI: I'll meet up with Manik and Bela in NE today/tomorrow.

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

okey; Steve - when do you expect Hibernate 3.3 to go CR/GA ?

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

Ok - so yes, we need to run with seperate configurations; lets try and
get such a config example together while you are here in NE.

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

I think it is more a question about what you and PM want I assume ?
Hibernate is not dependent on JBossCache and I personally would be fine
saying that if users want to use a clustered JBossCache then it requires
JDK 5 so if you want it you need to use JDK 5.

/max

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



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