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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
