Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
FYI: I'll meet up with Manik and Bela in NE today/tomorrow. 1) 2.0.0.GA will not be out for a while. Planning a long CR run and coinciding GA with JGroups 2.5, circa early June. okey; Steve - when do you expect Hibernate 3.3 to go CR/GA ? 2) When you say separate caches, you would need separate cache instances if they were to run with separate configurations. (To reduce the network resource overhead, they could use a single multiplexed JGroups channel). Region based caches is a long way off (3.0.0 timeframe?) Ok - so yes, we need to run with seperate configurations; lets try and get such a config example together while you are here in NE. 3) JBoss Cache 2.0.0.GA will only be supported under Java 5. A retroweaved 1.4 compat binary *could* be built but for now this will *not* be supported. [1]. As such, I think there will always be a need for JBoss Cache 2.0.0 and 1.4.0 support in Hibernate - unless you foresee Hibernate usage with JDK 1.4 as an outlying minority that can be ignored here. I think it is more a question about what you and PM want I assume ? Hibernate is not dependent on JBossCache and I personally would be fine saying that if users want to use a clustered JBossCache then it requires JDK 5 so if you want it you need to use JDK 5. /max Cheers, Manik [1] http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHabaneroJava1.4 On 10 Apr 2007, at 22:23, Brian Stansberry wrote: Max Rydahl Andersen wrote: 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. sounds good. Could you provide an good default fallback setup for hibernate to run with ? You mean one with a multiplexer? Right now a multiplexer gets injected into the cache; JBC has no mechanism to create one itself. Sounds like we'll need to deal with that. 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. So I guess we just won't have good jbosscache integration before 2.5; similar that it won't work good before Hibernate 3.3. Is that a problem ? Just that JG 2.5 requires JDK 5. AIUI, Hibernate 3.3 will support JDK 1.4. JBC 2.0 will have a retroweaved version that works with JDK 1.4 and that should work fine with JGroups 2.4.x. So, you can make Hibenate 3.3 + JBC work on JDK 1.4, but the multiplexer stuff won't work well. Confusing. Re: #4 : what exactly are these differences? Now is the time to merge it back... snip/ The fix I did was just to 1) have the org.hibernate.cache.Cache impl make use of this API and Got it. 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. eh - ok, sounds bad. Yes, this was a hack to allow EJB3 entity clustering to work when people didn't specify a region prefix. (See below for more on why that's an issue). I certainly wouldn't mind seeing this go away. Isn't it better to just use hibernate.cache.region_prefix to disambiguate the regions per sessionfactory ? Sure. IIRC, if you specify a region_prefix that becomes part of the region name passed to o.h.c.TreeCache, in which case the hack that prevents replication would be bypassed. I don't think querycache region is the only one that would have problems if you are using the same physical cache for multiple sessionfactories. e.g. if a org.company.model.Customer exists in both you would have troubles with the entity cache. 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. Today you should not use the same cache across deployment; that's a big nono. JBoss AS currently deploys a single JBC instance for use as a shared cache across EJB3 deployments. If you specify org.jboss.ejb3.entity.TreeCacheProviderHook, that's what you get unless you go out of your way to deploy a separate cache. The design decisions that led to doing it that way predate me, but I assume its due to the hassle of deploying multiple JGroups channels. The separation of caches has more to do with having different semantics with respect to replication, locking and put/remove operations. 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
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
Sorry about jumping in on this so late, just back from vacation and still ploughing through backlog. 1) 2.0.0.GA will not be out for a while. Planning a long CR run and coinciding GA with JGroups 2.5, circa early June. 2) When you say separate caches, you would need separate cache instances if they were to run with separate configurations. (To reduce the network resource overhead, they could use a single multiplexed JGroups channel). Region based caches is a long way off (3.0.0 timeframe?) 3) JBoss Cache 2.0.0.GA will only be supported under Java 5. A retroweaved 1.4 compat binary *could* be built but for now this will *not* be supported. [1]. As such, I think there will always be a need for JBoss Cache 2.0.0 and 1.4.0 support in Hibernate - unless you foresee Hibernate usage with JDK 1.4 as an outlying minority that can be ignored here. 4) Steve, re: the TM issue, how could we delegate this to a strategy? At the moment we register Synchronizations directly with the TM. Are you suggesting that Hibernate injects the strategy into a JBC instance and the JBC instance registers the Synchronization there instead of the TM? If this is so, does a strategy implement any standard interface so as not to couple JBC and Hibernate? Cheers, Manik [1] http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHabaneroJava1.4 On 10 Apr 2007, at 22:23, Brian Stansberry wrote: Max Rydahl Andersen wrote: 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. sounds good. Could you provide an good default fallback setup for hibernate to run with ? You mean one with a multiplexer? Right now a multiplexer gets injected into the cache; JBC has no mechanism to create one itself. Sounds like we'll need to deal with that. 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. So I guess we just won't have good jbosscache integration before 2.5; similar that it won't work good before Hibernate 3.3. Is that a problem ? Just that JG 2.5 requires JDK 5. AIUI, Hibernate 3.3 will support JDK 1.4. JBC 2.0 will have a retroweaved version that works with JDK 1.4 and that should work fine with JGroups 2.4.x. So, you can make Hibenate 3.3 + JBC work on JDK 1.4, but the multiplexer stuff won't work well. Confusing. Re: #4 : what exactly are these differences? Now is the time to merge it back... snip/ The fix I did was just to 1) have the org.hibernate.cache.Cache impl make use of this API and Got it. 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. eh - ok, sounds bad. Yes, this was a hack to allow EJB3 entity clustering to work when people didn't specify a region prefix. (See below for more on why that's an issue). I certainly wouldn't mind seeing this go away. Isn't it better to just use hibernate.cache.region_prefix to disambiguate the regions per sessionfactory ? Sure. IIRC, if you specify a region_prefix that becomes part of the region name passed to o.h.c.TreeCache, in which case the hack that prevents replication would be bypassed. I don't think querycache region is the only one that would have problems if you are using the same physical cache for multiple sessionfactories. e.g. if a org.company.model.Customer exists in both you would have troubles with the entity cache. 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. Today you should not use the same cache across deployment; that's a big nono. JBoss AS currently deploys a single JBC instance for use as a shared cache across EJB3 deployments. If you specify org.jboss.ejb3.entity.TreeCacheProviderHook, that's what you get unless you go out of your way to deploy a separate cache. The design decisions that led to doing it that way predate me, but I assume its due to the hassle of deploying multiple JGroups channels. The separation of caches has more to do with having different semantics with respect to replication, locking and put/remove operations. 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
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
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. Ugh! So more than likely we will need two (or more) separate implementations for JBC again (multiplexed vs not, etc). Do you know the timeframe for 2.0 to go GA? 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/docs/1.4.1/TreeCache/en/html/treecache_marshaller.html. 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. I'm not sure I am tracking on this particular last point. You mean that the classloader trickeration is unnecessary if we move to ...? Or that not replicating the query cache is unnecessary if we move to ...? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
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. ok. 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. sounds good. Could you provide an good default fallback setup for hibernate to run with ? 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. So I guess we just won't have good jbosscache integration before 2.5; similar that it won't work good before Hibernate 3.3. Is that a problem ? 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/docs/1.4.1/TreeCache/en/html/treecache_marshaller.html. I understand that part. The fix I did was just to 1) have the org.hibernate.cache.Cache impl make use of this API and Got it. 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. eh - ok, sounds bad. Isn't it better to just use hibernate.cache.region_prefix to disambiguate the regions per sessionfactory ? I don't think querycache region is the only one that would have problems if you are using the same physical cache for multiple sessionfactories. e.g. if a org.company.model.Customer exists in both you would have troubles with the entity cache. 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. Today you should not use the same cache across deployment; that's a big nono. The separation of caches has more to do with having different semantics with respect to replication, locking and put/remove operations. 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. Don't forget this one - manik ? :) /max /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
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
Steve Ebersole wrote:
Re: #4 : what exactly are these differences? Now is the time to
merge it back...
Forgot to attach the diff to my last message. Here it is.
- Brian
---
C:\dev\hibernate\Branch_3_2\Hibernate3\src\org\hibernate\cache\TreeCache.java
Mon Feb 19 17:05:11 2007
+++ C:\dev\jboss\jboss-4.2\ejb3\src\main\org\jboss\ejb3\entity\JBCCache.java
Mon Feb 19 17:12:35 2007
@@ -1,5 +1,25 @@
-//$Id: TreeCache.java 9965 2006-05-30 18:00:28Z [EMAIL PROTECTED] $
-package org.hibernate.cache;
+/*
+ * JBoss, Home of Professional Open Source.
+ * Copyright 2006, Red Hat Middleware LLC, and individual contributors
+ * as indicated by the @author tags. See the copyright.txt file in the
+ * distribution for a full listing of individual contributors.
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as
+ * published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this software; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
+ */
+package org.jboss.ejb3.entity;
import java.util.HashMap;
import java.util.Iterator;
@@ -12,17 +32,24 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.hibernate.cache.Cache;
+import org.hibernate.cache.CacheException;
+import org.hibernate.cache.StandardQueryCache;
+import org.hibernate.cache.UpdateTimestampsCache;
import org.jboss.cache.Fqn;
+import org.jboss.cache.config.Option;
import org.jboss.cache.lock.TimeoutException;
/**
- * Represents a particular region within the given JBossCache TreeCache.
+ * Subclass of the standard codeorg.hibernate.cache.TreeCache/code used as
+ * a workaround until issues related to JBCLUSTER-150 are resolved in
Hibernate.
*
* @author Gavin King
+ * @author Brian Stansberry
*/
-public class TreeCache implements Cache {
+public class JBCCache implements Cache {
- private static final Log log = LogFactory.getLog(TreeCache.class);
+ private static final Log log = LogFactory.getLog(JBCCache.class);
private static final String ITEM = item;
@@ -30,13 +57,40 @@
private final String regionName;
private final Fqn regionFqn;
private final TransactionManager transactionManager;
+private boolean localWritesOnly;
- public TreeCache(org.jboss.cache.TreeCache cache, String regionName,
TransactionManager transactionManager)
+ public JBCCache(org.jboss.cache.TreeCache cache, String regionName,
TransactionManager transactionManager)
throws CacheException {
this.cache = cache;
this.regionName = regionName;
this.regionFqn = Fqn.fromString( regionName.replace( '.', '/' )
);
this.transactionManager = transactionManager;
+if (cache.getUseRegionBasedMarshalling())
+{
+ localWritesOnly =
StandardQueryCache.class.getName().equals(regionName);
+
+ boolean fetchState = cache.getFetchInMemoryState();
+ try
+ {
+ // We don't want a state transfer for the StandardQueryCache,
+ // as it can include classes from multiple scoped classloaders
+ if (localWritesOnly)
+ cache.setFetchInMemoryState(false);
+
+ // We always activate
+ activateCacheRegion(regionFqn.toString());
+ }
+ finally
+ {
+ // Restore the normal state transfer setting
+ if (localWritesOnly)
+ cache.setFetchInMemoryState(fetchState);
+ }
+}
+else
+{
+ log.debug(TreeCache is not configured for region based
marshalling);
+}
}
public Object get(Object key) throws CacheException {
@@ -60,7 +114,14 @@
public void update(Object key, Object value) throws CacheException {
try {
- cache.put( new Fqn( regionFqn, key ), ITEM, value );
+if (localWritesOnly) {
+ Option option = new Option();
+ option.setCacheModeLocal(true);
+ cache.put( new Fqn( regionFqn, key ), ITEM, value, option );
+}
+else {
+cache.put( new Fqn( regionFqn, key ), ITEM, value );
+}
}
catch (Exception e) {
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
Max Rydahl Andersen wrote: 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. sounds good. Could you provide an good default fallback setup for hibernate to run with ? You mean one with a multiplexer? Right now a multiplexer gets injected into the cache; JBC has no mechanism to create one itself. Sounds like we'll need to deal with that. 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. So I guess we just won't have good jbosscache integration before 2.5; similar that it won't work good before Hibernate 3.3. Is that a problem ? Just that JG 2.5 requires JDK 5. AIUI, Hibernate 3.3 will support JDK 1.4. JBC 2.0 will have a retroweaved version that works with JDK 1.4 and that should work fine with JGroups 2.4.x. So, you can make Hibenate 3.3 + JBC work on JDK 1.4, but the multiplexer stuff won't work well. Confusing. Re: #4 : what exactly are these differences? Now is the time to merge it back... snip/ The fix I did was just to 1) have the org.hibernate.cache.Cache impl make use of this API and Got it. 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. eh - ok, sounds bad. Yes, this was a hack to allow EJB3 entity clustering to work when people didn't specify a region prefix. (See below for more on why that's an issue). I certainly wouldn't mind seeing this go away. Isn't it better to just use hibernate.cache.region_prefix to disambiguate the regions per sessionfactory ? Sure. IIRC, if you specify a region_prefix that becomes part of the region name passed to o.h.c.TreeCache, in which case the hack that prevents replication would be bypassed. I don't think querycache region is the only one that would have problems if you are using the same physical cache for multiple sessionfactories. e.g. if a org.company.model.Customer exists in both you would have troubles with the entity cache. 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. Today you should not use the same cache across deployment; that's a big nono. JBoss AS currently deploys a single JBC instance for use as a shared cache across EJB3 deployments. If you specify org.jboss.ejb3.entity.TreeCacheProviderHook, that's what you get unless you go out of your way to deploy a separate cache. The design decisions that led to doing it that way predate me, but I assume its due to the hassle of deploying multiple JGroups channels. The separation of caches has more to do with having different semantics with respect to replication, locking and put/remove operations. 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. Don't forget this one - manik ? :) I think he's teaching this week?? -- Brian Stansberry Lead, AS Clustering 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
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
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. 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. 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/docs/1.4.1.SP2/TreeCache/en/html/configuration.html, 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 ___ 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
