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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
