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

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