Manik can better comment on plans for having separate configurations
(e.g. optimistic vs pessimistic, invalidation vs replication) for
different regions of the cache. But, I know it's not a soonish thing.
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.
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.
Ugh! So more than likely we will need two (or more) separate
implementations for JBC again (multiplexed vs not, etc). Do you know
the timeframe for 2.0 to go GA?
The issue here is that if you send a message to replicate type Foo, on
the remote node the thread coming up from JGroups that handles the
message needs access to the Foo class in order to deserialize Foo and
put it in the cache. Determining the correct classloader to use is a
problem if the cache is shared between multiple deployments. There's
a standard JBC API to handle this use case, as discussed at
http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1/TreeCache/en/html/treecache_marshaller.html.
The fix I did was just to 1) have the org.hibernate.cache.Cache impl
make use of this API and 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. A diff between the EJB3 class and o.h.c.TreeCache is
attached. An equivalent thing was done for OptimisticTreeCache.
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.
I'm not sure I am tracking on this particular last point. You mean that
the classloader trickeration is unnecessary "if we move to ..."? Or
that not replicating the query cache is unnecessary "if we move to ..."?
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
