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

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.

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(a)redhat.com > -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani