April 2007 - jbosscache-dev - Jboss List Archives

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

by 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(a)redhat.com

17 years