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

[Max Rydahl Andersen]

i'll follow up in the forum thread  
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989163#3989163

/max

> 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/
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com