FYI: I'll meet up with Manik and Bela in NE today/tomorrow.
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.
okey; Steve - when do you expect Hibernate 3.3 to go CR/GA ?
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?)
Ok - so yes, we need to run with seperate configurations; lets try and
get such a config example together while you are here in NE.
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.
I think it is more a question about what you and PM want I assume ?
Hibernate is not dependent on JBossCache and I personally would be fine
saying that if users want to use a clustered JBossCache then it requires
JDK 5 so if you want it you need to use JDK 5.
/max
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
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
