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