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