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.
>>>> Re: #4 : what exactly are these differences? Now is the time to
>>>> merge it back...
>> 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
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??
Lead, AS Clustering
JBoss, a division of Red Hat