1:19 p.m.
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
1:25 p.m.
New subject: [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 steve.ebersole(a)jboss.com $
-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 <code>org.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) {
throw new CacheException(e);
@@ -70,8 +131,23 @@
public void put(Object key, Object value) throws CacheException {
Transaction tx = suspend();
try {
- //do the failfast put outside the scope of the JTA txn
- cache.putFailFast( new Fqn( regionFqn, key ), ITEM, value, 0 );
+ if (localWritesOnly) {
+ Option option = new Option();
+ option.setCacheModeLocal(true);
+ // Overloaded method isn't available, so have to use InvocationContext
+ cache.getInvocationContext().setOptionOverrides(option);
+ try {
+ // do the failfast put outside the scope of the JTA txn
+ cache.putFailFast( new Fqn( regionFqn, key ), ITEM, value, 0 );
+ }
+ finally {
+ cache.getInvocationContext().setOptionOverrides(null);
+ }
+ }
+ else {
+ //do the failfast put outside the scope of the JTA txn
+ cache.putFailFast( new Fqn( regionFqn, key ), ITEM, value, 0 );
+ }
}
catch (TimeoutException te) {
//ignore!
@@ -109,7 +185,14 @@
public void remove(Object key) throws CacheException {
try {
- cache.remove( new Fqn( regionFqn, key ) );
+ if (localWritesOnly) {
+ Option option = new Option();
+ option.setCacheModeLocal(true);
+ cache.remove( new Fqn( regionFqn, key ), option );
+ }
+ else {
+ cache.remove( new Fqn( regionFqn, key ) );
+ }
}
catch (Exception e) {
throw new CacheException(e);
@@ -127,13 +210,21 @@
public void destroy() throws CacheException {
try {
- // NOTE : evict() operates locally only (i.e., does not propogate
- // to any other nodes in the potential cluster). This is
- // exactly what is needed when we destroy() here; destroy() is used
- // as part of the process of shutting down a SessionFactory; thus
- // these removals should not be propogated
- cache.evict( regionFqn );
- }
+ // NOTE : Hibernate's class uses evict() but that isn't recursive!
+ //cache.evict( regionFqn );
+ Option opt = new Option();
+ opt.setCacheModeLocal(true);
+ cache.remove(regionFqn, opt);
+
+ if (cache.getUseRegionBasedMarshalling() &&
!isSharedClassLoaderRegion(regionName))
+ {
+ inactivateCacheRegion();
+ }
+ }
+ catch (CacheException e)
+ {
+ throw e;
+ }
catch( Exception e ) {
throw new CacheException( e );
}
@@ -201,5 +292,59 @@
public String toString() {
return "TreeCache(" + regionName + ')';
}
-
+
+ private boolean isSharedClassLoaderRegion(String regionName)
+ {
+ return (StandardQueryCache.class.getName().equals(regionName)
+ || UpdateTimestampsCache.class.getName().equals(regionName));
+ }
+
+ private void activateCacheRegion(String regionName) throws CacheException
+ {
+ String fqnString = regionFqn.toString();
+ // FIXME -- find a way that doesn't involve this API
+ if (cache.getMarshaller().isInactive(fqnString))
+ {
+ try
+ {
+ // Only register the classloader if it's not a shared region.
+ // If it's shared, no single classloader is valid
+ if (!isSharedClassLoaderRegion(regionName))
+ {
+ cache.registerClassLoader(fqnString,
Thread.currentThread().getContextClassLoader());
+ }
+ cache.activateRegion(fqnString);
+ }
+ catch (Exception e)
+ {
+ throw new CacheException("Problem activating region " +
regionName, e);
+ }
+ }
+ else
+ {
+ log.debug("activateCacheRegion(): Region " + fqnString + " is
already active");
+ }
+ }
+
+ private void inactivateCacheRegion() throws CacheException
+ {
+ String fqnString = regionFqn.toString();
+ // FIXME -- find a way that doesn't involve this API
+ if (!cache.getMarshaller().isInactive(fqnString))
+ {
+ try
+ {
+ cache.inactivateRegion(fqnString);
+ cache.unregisterClassLoader(fqnString);
+ }
+ catch (Exception e)
+ {
+ throw new CacheException("Problem activating region " + fqnString,
e);
+ }
+ }
+ else
+ {
+ log.debug("inactivateCacheRegion(): Region " + fqnString + " is
already inactive");
+ }
+ }
}
9:02 p.m.
New subject: [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/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.
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 ..."?
6238
days inactive
6238
days old
jbosscache-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Brian Stansberry -
Steve Ebersole