[hibernate-dev] RE: Replication problems with query cache and JBoss Cache

[Brian Stansberry]

Follow up to this earlier thread...

Using the JBC classloader registration API won't work right now due to
http://jira.jboss.com/jira/browse/JBCACHE-876.  With the query cache, a
user class can end up as part of an Fqn; JBC doesn't deal with this yet.

The RH stacks people are looking for a solution this week; one
workaround idea I had was to use persistence.xml to replace the
StandardQueryCacheFactory with a custom one.  This custom QueryCache
would use the JBC Option API to make all writes to JBC for the query
cache local only (i.e. non-replicated).

The entity cache and update timestamps cache would still replicate.

Do you guys see any problem with such an approach (besides ugliness);
e.g. any problems with the non-replicated query caches falling out of
sync with the entities?

- Brian

Brian Stansberry wrote:
> Steve Ebersole wrote:
>> (1)
>> 
>> The FQN is exactly the regionName value passed in to
>> CacheProvider.buildCache().  The structure of the region names are
>> determined by the callers of this method, and it is different based
>> on the intended usage of the built region.
>> 
>> For entity caches the region name follows the pattern:
>> {prefix.}rootEntityName 
>> 
>> For collection caches the pattern is:
>> {prefix.}owningEntityName.collectionPropertyName
>> 
>> For query caches, there is a default which is named:
>> {prefix.}org.hibernate.cache.StandardQueryCache
>> 
>> although users can specify additional query cache regions:
>> {prefix.}userSuppliedRegionName
>> 
> 
> Carlo, for an EJB3 entity deployment where the query cache is
> enabled, is there a separate query cache region set up for
> that deployment? Or is the default one used?  If the former,
> we can register the proper classloader for each query cache
> region.  If the latter, there is no single correct
> classloader for the default region and we have a problem.
> 
>> The dots are transformed to slashes for TreeCache based providers;
>> although note that there was a bug in how this was done early which
>> caused a very flat structure.  The nodes were named correctly, but
>> apparently we were not constructing the actual FQN correctly causing
>> all regions to be created flat off of the root node.
>> 
>> 
>> (2)
>> 
>> The vast majority of cache regions are built when the SessionFactory
>> is being built.  So this is probably done during deployment.  I
>> assume EJB3 deployer properly sets up a context classloader, though
>> not certain.  But regardless, the classloader used would need access
>> to the entity classes as they would be need during construction of
>> the SessionFactory anyway.  Typically deployers in JBoss are pretty
>> smart and switch to the *deployment's* classloader before invoking
>> on the deployment...
> 
> Yeah, I figured that's the case.
> 
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: Tuesday, November 14, 2006 11:23 AM
>> To: Steve Ebersole; Max Andersen
>> Subject: FW: Replication problems with query cache and JBoss Cache
>> 
>> Guys,
>> 
>> I've tried sending the following to hibernate-dev a couple times and
>> it rejects me (I registered), so I'll just send it to you directly.
>> 
>> Brian Stansberry wrote:
>>> There are some classloader issues with JBoss Cache's deserialization
>>> of replicated query cache entries (see
>>> http://jira.jboss.com/jira/browse/JBCLUSTER-150).  I'm hoping these
>>> will be pretty easy to resolve using some JBC APIs meant for this
>>> kind of problem, but need confirmation on a couple points:
>>> 
>>> 1) What's the structure of the Fqn where query cache entries are
>>> stored in JBC?  Specifically, how does it relate to the regionName
>>> parameter that's passed to CacheProvider.buildCache(String
>>> regionName, Properties properties)?  Logically, is it something
>>> like: 
>>> 
>>> /somepath/regionName/queryCache/entry
>>> /somepath/regionName/entityCache/entry
>>> 
>>> or..
>>> 
>>> /somepath/queryCache/regionName/entry
>>> /somepath/entityCache/regionName/entry
>>> 
>>> or (I hope not)
>>> 
>>> /somepath/queryCache/entry
>>> /somepath/entityCache/regionName/entry
>>> 
>>> 2) What's the thread context class loader when
>>> CacheProvider.buildCache() is invoked? (I'm thinking here about an
>>> EJB3 entity bean deployment. Probably better asked on the JBoss
>>> EJB3 forum, but I'll start here.) 
>>> 
>>> If all the query cache entries for a region are segregated under
>>> particular fqn, and the thread context class loader has visibility
>>> to the entity classes, this problem should be easily solved using
>>> the JBC activate/inactivateRegion API.
>>> 
>>> Sorry for the basic questions.
>>> 
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss, a division of Red Hat
>>> Ph: 510-396-3864
>>> skype: bstansberry



Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry

IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/