April 2007 - jbosscache-dev - Jboss List Archives

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-140 build.10 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-jdk14 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache build.1019 Build Successful

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration

by Brian Stansberry

Max Rydahl Andersen wrote: > >> So I started breaking out 3.3 as a separate code base on the Hibernate >> svn trunk. The first thing done was this org.hibernate.cache.Cache >> splitting. So at this point we now have the ability to be completely >> free in how we cache entity-data versus collection-data versus >> query-data versus timestamps-data within the same "second level cache". > > Cool. > >> But now looking back at #1, I am no longer certain of the conclusions; >> and to me the wiki did not make it clear to me what the "long term" >> solution was supposed to be (nor really what the "short term" solution >> is/was either). Anyone remember the specific conclusions with regards >> to this point? > > Long-term: > In Hibernate - use seperate caches which you have done for 3.3 > In JBoss Cache - as it stands now you would have to use differnt > jbosscache configurations. > In older versions of JBC you would need different treecache.xml; but > that has been simplified > in later JBC's AFAIK - Manik/galder ? Depending on this and wether > optimistic locking is a global > or node level-and-down setting users might need some less or more > complex "writing jbosscache config files > for hibernate" examples ;) > > Short-term: > Write a cacheprovider that would use different jbosscaches for each > "type" of cache. > Not sure if that still makes sense. > Manik can better comment on plans for having separate configurations (e.g. optimistic vs pessimistic, invalidation vs replication) for different regions of the cache. But, I know it's not a soonish thing. That means if you want different behavior for the different "types" of caches you need separate caches. If the JGroups multiplexer is available, that's not too bad, as the caches can share a channel. If we think it through well, they can likely share an overall config file, with the different "types" just overriding a couple properties that are relevant. If the JGroups multiplexer isn't available then having a separate cache for each "type" is a royal pain, since you have multiple channels that need to have unique ports, etc. And we need to assume that the multiplexer won't be available in any non-JDK5 env, since the earliest JG release where it's reliable is 2.5. >> Re: #4 : what exactly are these differences? Now is the time to merge >> it back... > > I recall these as being Bryan 2 things: > > 1) setting up JBC/Cacheprovider so it would use the correct classloader > when loading data from the cache. > > 2) doing some "mutations"/magic-lookup of the cache region names to know > which classloader to use > (this might just me having nightmares, so need Bryan to certify ;) If > it's true we would > need to look into the practicallity of that solution. > The issue here is that if you send a message to replicate type Foo, on the remote node the thread coming up from JGroups that handles the message needs access to the Foo class in order to deserialize Foo and put it in the cache. Determining the correct classloader to use is a problem if the cache is shared between multiple deployments. There's a standard JBC API to handle this use case, as discussed at http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc.... The fix I did was just to 1) have the org.hibernate.cache.Cache impl make use of this API and 2) prevent replication of the org.hibernate.cache.StandardQueryCache region, since that region could be shared between multiple deployments and hence there's no 'correct' classloader. A diff between the EJB3 class and o.h.c.TreeCache is attached. An equivalent thing was done for OptimisticTreeCache. If we move to a mode where we have one cache (or set of caches) per deployment, then this kind of stuff becomes unnecessary. But, again, that requires the JGroups multiplexer. >> Re: #5 : what about the other solution I proposed where instead of >> registering synchs directly with the TC/TM, you instead delegate it to >> a strategy which can route the request back through Hibernate; >> Hibernate can then manage ordering the callbacks? > > I don't recall more progress on that topic. > > /max > >> Re: #6 : I'm actually in favor of just moving to the new (2.0) API; >> easier from a management perspective. >>> Ok, so my notes from the call, based on issues from the wiki >>> >>> >>> 1. Multiple caches will probably only formally make it in the next >>> major Hibernate release - 3.3. >>> >>> 2 Notes on putForExternalRead() functionality, in addition to the >>> solution presented on the wiki: >>> - PFER only goes through if node does not exist; no-op otherwise >>> - Force asynchronous mode for replication or invalidation to prevent >>> any blocking >>> - 0ms lock timeout to prevent any blocking here either. If this >>> fails, PFER is a no-op >>> - no to separate thread necessary, since we will be operating with a >>> 0ms timeout, async replication and a no-op if the node exists. The >>> only real chance of any blocking here is JGroups FC which is >>> considered small enough a case. >>> >>> 3. Since JBC 1.4.1.SP1, write locks are not acquired on parents when >>> adding or removing children, to be more accurate to repeatable read >>> semantics. WLs can still be acquired on parents if enabled in the >>> configuration (see "LockParentForChildInsertRemove" in >>> http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc..., >>> which defaults to false). As such, this contention should no longer >>> be a problem. >>> >>> 4. Brian implemented for EJB3 clustering in AS 4.2, will make it's >>> way back into HIbernate in the 3.3 timeframe? >>> >>> 5. Do nothing for now since the urgency is removed. Only fails on >>> old versions of JBoss TS. In future (JBC 2.1 timeframe) look at what >>> the microcontainer has to offer with synchronisation registrations. >>> >>> 6. Coordination issue >>> >>> 7. Galder to come back with more details here, but general consensus >>> is not to perform transparent retries. >>> Feel free to add stuff I may have missed or further thoughts. >>> Very useful and productive call! >>> >>> Cheers, >>> Manik -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

17 years, 7 months

2
2
0 / 0

Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration

by Steve Ebersole

> Long-term: > In Hibernate - use seperate caches which you have done for 3.3 Not quite true. What I have done so far is to introduce this possibility. What happens right now is that there is only a single RegionFactory implementation which simply "bridges" to the old CacheProviders. Or perhaps what you meant was "separate caches" = "separate regions", as opposed to "separate cache instances"? > In JBoss Cache - as it stands now you would have to use differnt > jbosscache configurations. > In older versions of JBC you would need different treecache.xml; but > that has been simplified > in later JBC's AFAIK - Manik/galder ? Depending on this and wether > optimistic locking is a global > or node level-and-down setting users might need some less or more > complex "writing jbosscache config files > for hibernate" examples ;) I think this is going to depend exactly on the different configuration options/parameters that need to get applied to the cache instances used by the different Hibernate regions (of course until we have the capability to natively configure these per region within JBC).

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

jboss-cache-testsuite-jdk14 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-dev April 2007