RE: Replication problems with query cache and JBoss Cache
by 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/
18 years
hibernate testsuite
by Aleksandar Kostadinov
Hi
Is it possible/easy to create a target in the hibernate's build.xml
which cleans the test database as specified in hibernate.properties?
This would be very useful for the continuous builds.
Thanks,
Aleksandar Kostadinov
18 years
hibernate mysql testsuite
by Aleksandar Kostadinov
Take a look at:
http://cruisecontrol.jboss.com/cc/buildresults/hibernate-mysql-testsuite
There are much failings.
As the initial problem as I think was a mysql bug that is fixed in
4.1.18 I think it's worth installing newer version.
Could you suggest which version will best suite your needs (4.1.latest,
5.0.latest)?
btw. hibernate can be tested against innodb and myisam. Currently it is
tested only against innodb. Is this ok?
Thanks,
Aleksandar Kostadinov
18 years
