Sorry about jumping in on this so late, just back from vacation and
still ploughing through backlog.
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.
4) Steve, re: the TM issue, how could we delegate this to a
strategy? At the moment we register Synchronizations directly with
the TM. Are you suggesting that Hibernate injects the strategy into
a JBC instance and the JBC instance registers the Synchronization
there instead of the TM? If this is so, does a strategy implement
any standard interface so as not to couple JBC and Hibernate?
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
[EMAIL PROTECTED]
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: [EMAIL PROTECTED]
Telephone: +44 7786 702 706
MSN: [EMAIL PROTECTED]
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
