[hibernate-dev] Re: JBoss Cache and Hibernate Integration

[Steve Ebersole]

> 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 ..."?