JBoss Cache SVN: r7206 - core/trunk/src/test/java/org/jboss/cache/integration/websession.
by jbosscache-commits＠lists.jboss.org
Author: bstansberry(a)jboss.com
Date: 2008-11-26 21:05:06 -0500 (Wed, 26 Nov 2008)
New Revision: 7206
Modified:
core/trunk/src/test/java/org/jboss/cache/integration/websession/BuddyReplicationFailoverTest.java
Log:
Add tests of more failure scenarios seen during AS soak tests
Modified: core/trunk/src/test/java/org/jboss/cache/integration/websession/BuddyReplicationFailoverTest.java
===================================================================
--- core/trunk/src/test/java/org/jboss/cache/integration/websession/BuddyReplicationFailoverTest.java 2008-11-27 02:04:28 UTC (rev 7205)
+++ core/trunk/src/test/java/org/jboss/cache/integration/websession/BuddyReplicationFailoverTest.java 2008-11-27 02:05:06 UTC (rev 7206)
@@ -65,6 +65,286 @@
return true;
}
+ public void testFailoverAndImmediateInvalidate()
+ {
+ int attr = 0;
+
+ SessionManager mgr0 = getSessionManagers().get(0);
+ SessionManager mgr1 = getSessionManagers().get(1);
+ SessionManager mgr2 = getSessionManagers().get(2);
+ SessionManager mgr3 = getSessionManagers().get(3);
+
+ String contextHostName = mgr0.getContextHostName();
+
+ // Create the session
+ SetAttributesServlet sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ ReplicationListener replListener1 = getReplicationListener(mgr1.getCache());
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ Request req = new Request(mgr0, null, sas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ String sessionId = sas.getSessionId();
+ assert sessionId != null : "session id is null";
+ // validate cache contents
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr0.getCache(), mgr1.getCache());
+
+ // Modify the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr0, sessionId, sas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ // Fail over; request reads the session and then modifies the session
+ GetAttributesServlet gas = new GetAttributesServlet(Collections.singleton(KEY));
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ MultipleActionServlet mas = new MultipleActionServlet(gas, sas);
+ ReplicationListener replListener0 = getReplicationListener(mgr0.getCache());
+ replListener0.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr3, sessionId, mas);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ assert sessionId.equals(mas.getSessionId()) : "wrong session id; expected " + sessionId + " got " + mas.getSessionId();
+ Integer integer = (Integer) gas.getReadAttributes().get(KEY);
+ assert integer != null : "null attribute value";
+ assert integer.intValue() == (attr - 2) : "wrong val " + integer + " expected " + (attr -2);
+
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr3.getCache(), mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+
+ // Invalidate the session
+ InvalidationServlet invs = new InvalidationServlet();
+ replListener0.expectWithTx(RemoveNodeCommand.class);
+
+ req = new Request(mgr3, sessionId, invs);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+ }
+
+ public void testFailoverToOwnerAndImmediatelyInvalidate()
+ {
+ int attr = 0;
+
+ SessionManager mgr0 = getSessionManagers().get(0);
+ SessionManager mgr1 = getSessionManagers().get(1);
+ SessionManager mgr2 = getSessionManagers().get(2);
+ SessionManager mgr3 = getSessionManagers().get(3);
+
+ String contextHostName = mgr0.getContextHostName();
+
+ // Create the session
+ SetAttributesServlet sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ ReplicationListener replListener2 = getReplicationListener(mgr2.getCache());
+ replListener2.expectWithTx(PutDataMapCommand.class);
+
+ Request req = new Request(mgr1, null, sas);
+ req.execute();
+ replListener2.waitForReplicationToOccur();
+
+ String sessionId = sas.getSessionId();
+ assert sessionId != null : "session id is null";
+ // validate cache contents
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr1.getCache(), mgr2.getCache());
+
+ // Modify the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener2.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr1, sessionId, sas);
+ req.execute();
+ replListener2.waitForReplicationToOccur();
+
+ // Fail over; request reads the session and then modifies the session
+ GetAttributesServlet gas = new GetAttributesServlet(Collections.singleton(KEY));
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ MultipleActionServlet mas = new MultipleActionServlet(gas, sas);
+ ReplicationListener replListener1 = getReplicationListener(mgr1.getCache());
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr0, sessionId, mas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ assert sessionId.equals(mas.getSessionId()) : "wrong session id; expected " + sessionId + " got " + mas.getSessionId();
+ Integer integer = (Integer) gas.getReadAttributes().get(KEY);
+ assert integer != null : "null attribute value";
+ assert integer.intValue() == (attr - 2) : "wrong val " + integer + " expected " + (attr -2);
+
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr0.getCache(), mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+
+ // Invalidate the session
+ InvalidationServlet invs = new InvalidationServlet();
+ replListener1.expectWithTx(RemoveNodeCommand.class);
+
+ req = new Request(mgr0, sessionId, invs);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+ }
+
+ public void testFailoverAndInvalidate()
+ {
+ int attr = 0;
+
+ SessionManager mgr0 = getSessionManagers().get(0);
+ SessionManager mgr1 = getSessionManagers().get(1);
+ SessionManager mgr2 = getSessionManagers().get(2);
+ SessionManager mgr3 = getSessionManagers().get(3);
+
+ String contextHostName = mgr0.getContextHostName();
+
+ // Create the session
+ SetAttributesServlet sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ ReplicationListener replListener1 = getReplicationListener(mgr1.getCache());
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ Request req = new Request(mgr0, null, sas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ String sessionId = sas.getSessionId();
+ assert sessionId != null : "session id is null";
+ // validate cache contents
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr0.getCache(), mgr1.getCache());
+
+ // Modify the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr0, sessionId, sas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ // Fail over; request reads the session and then modifies the session
+ GetAttributesServlet gas = new GetAttributesServlet(Collections.singleton(KEY));
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ MultipleActionServlet mas = new MultipleActionServlet(gas, sas);
+ ReplicationListener replListener0 = getReplicationListener(mgr0.getCache());
+ replListener0.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr3, sessionId, mas);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ assert sessionId.equals(mas.getSessionId()) : "wrong session id; expected " + sessionId + " got " + mas.getSessionId();
+ Integer integer = (Integer) gas.getReadAttributes().get(KEY);
+ assert integer != null : "null attribute value";
+ assert integer.intValue() == (attr - 2) : "wrong val " + integer + " expected " + (attr -2);
+
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr3.getCache(), mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+
+ // Modify the session again
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener0.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr3, sessionId, sas);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ // Invalidate the session
+ InvalidationServlet invs = new InvalidationServlet();
+ replListener0.expectWithTx(RemoveNodeCommand.class);
+
+ req = new Request(mgr3, sessionId, invs);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+ }
+
+ public void testFailoverToOwnerAndInvalidate()
+ {
+ int attr = 0;
+
+ SessionManager mgr0 = getSessionManagers().get(0);
+ SessionManager mgr1 = getSessionManagers().get(1);
+ SessionManager mgr2 = getSessionManagers().get(2);
+ SessionManager mgr3 = getSessionManagers().get(3);
+
+ String contextHostName = mgr0.getContextHostName();
+
+ // Create the session
+ SetAttributesServlet sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ ReplicationListener replListener2 = getReplicationListener(mgr2.getCache());
+ replListener2.expectWithTx(PutDataMapCommand.class);
+
+ Request req = new Request(mgr1, null, sas);
+ req.execute();
+ replListener2.waitForReplicationToOccur();
+
+ String sessionId = sas.getSessionId();
+ assert sessionId != null : "session id is null";
+ // validate cache contents
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr1.getCache(), mgr2.getCache());
+
+ // Modify the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener2.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr1, sessionId, sas);
+ req.execute();
+ replListener2.waitForReplicationToOccur();
+
+ // Fail over; request reads the session and then modifies the session
+ GetAttributesServlet gas = new GetAttributesServlet(Collections.singleton(KEY));
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ MultipleActionServlet mas = new MultipleActionServlet(gas, sas);
+ ReplicationListener replListener1 = getReplicationListener(mgr1.getCache());
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr0, sessionId, mas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ assert sessionId.equals(mas.getSessionId()) : "wrong session id; expected " + sessionId + " got " + mas.getSessionId();
+ Integer integer = (Integer) gas.getReadAttributes().get(KEY);
+ assert integer != null : "null attribute value";
+ assert integer.intValue() == (attr - 2) : "wrong val " + integer + " expected " + (attr -2);
+
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr0.getCache(), mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+
+ // Modify the session again
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener1.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr0, sessionId, sas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ // Invalidate the session
+ InvalidationServlet invs = new InvalidationServlet();
+ replListener1.expectWithTx(RemoveNodeCommand.class);
+
+ req = new Request(mgr0, sessionId, invs);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+ }
+
public void testFailoverAndFailBack()
{
int attr = 0;
@@ -78,7 +358,7 @@
// Create the session
SetAttributesServlet sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
- ReplicationListener replListener1 = ReplicationListener.getReplicationListener(mgr1.getCache());
+ ReplicationListener replListener1 = getReplicationListener(mgr1.getCache());
replListener1.expectWithTx(PutDataMapCommand.class);
Request req = new Request(mgr0, null, sas);
@@ -89,6 +369,8 @@
assert sessionId != null : "session id is null";
// validate cache contents
BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr0.getCache(), mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
// Modify the session
sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
@@ -102,7 +384,7 @@
GetAttributesServlet gas = new GetAttributesServlet(Collections.singleton(KEY));
sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
MultipleActionServlet mas = new MultipleActionServlet(gas, sas);
- ReplicationListener replListener0 = ReplicationListener.getReplicationListener(mgr0.getCache());
+ ReplicationListener replListener0 = getReplicationListener(mgr0.getCache());
replListener0.expectWithTx(PutDataMapCommand.class);
req = new Request(mgr3, sessionId, mas);
@@ -116,6 +398,7 @@
BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr3.getCache(), mgr0.getCache());
BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
// Modify the session again
sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
@@ -142,6 +425,7 @@
BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr0.getCache(), mgr1.getCache());
BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
// Invalidate the session
InvalidationServlet invs = new InvalidationServlet();
@@ -155,5 +439,77 @@
BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+
+ gas = new GetAttributesServlet(Collections.singleton(KEY));
+ req = new Request(mgr0, sessionId, gas);
+ assert gas.getReadAttributes().get(KEY) == null : "session not cleaned up";
}
+
+ public void testInvalidateOnFailoverToBackup()
+ {
+ int attr = 0;
+
+ SessionManager mgr0 = getSessionManagers().get(0);
+ SessionManager mgr1 = getSessionManagers().get(1);
+ SessionManager mgr2 = getSessionManagers().get(2);
+ SessionManager mgr3 = getSessionManagers().get(3);
+
+ String contextHostName = mgr0.getContextHostName();
+
+ // Create the session
+ SetAttributesServlet sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ ReplicationListener replListener0 = getReplicationListener(mgr0.getCache());
+ replListener0.expectWithTx(PutDataMapCommand.class);
+
+ Request req = new Request(mgr3, null, sas);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ String sessionId = sas.getSessionId();
+ assert sessionId != null : "session id is null";
+ // validate cache contents
+ BuddyReplicationAssertions.assertBuddyBackup(contextHostName, sessionId, mgr3.getCache(), mgr0.getCache());
+
+ // Modify the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener0.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr3, sessionId, sas);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ // Passivate the session
+ mgr0.passivate(sessionId);
+ mgr1.passivate(sessionId);
+ mgr2.passivate(sessionId);
+ mgr3.passivate(sessionId);
+
+ // Reactivate the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ replListener0.expectWithTx(PutDataMapCommand.class);
+
+ req = new Request(mgr3, sessionId, sas);
+ req.execute();
+ replListener0.waitForReplicationToOccur();
+
+ // Invalidate the session
+ sas = new SetAttributesServlet(Collections.singletonMap(KEY, getAttributeValue(attr++)));
+ InvalidationServlet invs = new InvalidationServlet();
+ MultipleActionServlet mas = new MultipleActionServlet(sas, invs);
+ ReplicationListener replListener1 = getReplicationListener(mgr1.getCache());
+ replListener1.expectWithTx(PutDataMapCommand.class, RemoveNodeCommand.class);
+
+ req = new Request(mgr0, sessionId, mas);
+ req.execute();
+ replListener1.waitForReplicationToOccur();
+
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr0.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr1.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr2.getCache());
+ BuddyReplicationAssertions.assertUnrelated(contextHostName, sessionId, mgr3.getCache());
+
+ GetAttributesServlet gas = new GetAttributesServlet(Collections.singleton(KEY));
+ req = new Request(mgr0, sessionId, gas);
+ assert gas.getReadAttributes().get(KEY) == null : "session not cleaned up";
+ }
}
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7205 - core/trunk/src/test/java/org/jboss/cache/integration/websession/util.
by jbosscache-commits＠lists.jboss.org
Author: bstansberry(a)jboss.com
Date: 2008-11-26 21:04:28 -0500 (Wed, 26 Nov 2008)
New Revision: 7205
Modified:
core/trunk/src/test/java/org/jboss/cache/integration/websession/util/WebSessionTestBase.java
Log:
Couple the replication listeners to the caches
Modified: core/trunk/src/test/java/org/jboss/cache/integration/websession/util/WebSessionTestBase.java
===================================================================
--- core/trunk/src/test/java/org/jboss/cache/integration/websession/util/WebSessionTestBase.java 2008-11-26 21:12:09 UTC (rev 7204)
+++ core/trunk/src/test/java/org/jboss/cache/integration/websession/util/WebSessionTestBase.java 2008-11-27 02:04:28 UTC (rev 7205)
@@ -22,7 +22,9 @@
package org.jboss.cache.integration.websession.util;
+import java.util.HashMap;
import java.util.List;
+import java.util.Map;
import java.util.concurrent.atomic.AtomicInteger;
import org.jboss.cache.Cache;
@@ -31,6 +33,7 @@
import org.jboss.cache.integration.CacheManagerSupport;
import org.jboss.cache.integration.UnitTestCacheFactoryConfigurationRegistry;
import org.jboss.cache.integration.websession.util.WebAppMetadata.Granularity;
+import org.jboss.cache.util.internals.replicationlisteners.ReplicationListener;
import org.testng.annotations.AfterClass;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeClass;
@@ -48,6 +51,7 @@
private AtomicInteger testCount = new AtomicInteger();
private List<CacheManager> cacheManagers;
private List<SessionManager> sessionManagers;
+ private Map<Cache<Object, Object>, ReplicationListener> replicationListeners = new HashMap<Cache<Object, Object>, ReplicationListener>();
@BeforeClass(alwaysRun = true)
public void beforeClass() throws Exception
@@ -59,7 +63,10 @@
{
Cache<Object, Object> cache = cm.getCache(getCacheConfigName(), true);
if (cache.getCacheStatus() != CacheStatus.STARTED)
+ {
cache.start();
+ }
+ replicationListeners.put(cache, ReplicationListener.getReplicationListener(cache));
}
}
}
@@ -154,4 +161,9 @@
{
return Integer.valueOf(value);
}
+
+ protected ReplicationListener getReplicationListener(Cache<Object, Object> cache)
+ {
+ return replicationListeners.get(cache);
+ }
}
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7204 - core/trunk.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-26 16:12:09 -0500 (Wed, 26 Nov 2008)
New Revision: 7204
Modified:
core/trunk/pom.xml
Log:
Modified: core/trunk/pom.xml
===================================================================
--- core/trunk/pom.xml 2008-11-26 20:52:40 UTC (rev 7203)
+++ core/trunk/pom.xml 2008-11-26 21:12:09 UTC (rev 7204)
@@ -4,7 +4,7 @@
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<properties>
- <jbosscache-core-version>3.0.0-SNAPSHOT</jbosscache-core-version>
+ <jbosscache-core-version>3.0.1-SNAPSHOT</jbosscache-core-version>
<!-- By default only run tests in the "unit" group -->
<defaultTestGroup>unit</defaultTestGroup>
<!-- By default only generate Javadocs when we install the module. -->
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7203 - core/trunk/src/test/resources.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-26 15:52:40 -0500 (Wed, 26 Nov 2008)
New Revision: 7203
Modified:
core/trunk/src/test/resources/log4j.xml
Log:
Improved default log levels
Modified: core/trunk/src/test/resources/log4j.xml
===================================================================
--- core/trunk/src/test/resources/log4j.xml 2008-11-26 20:39:47 UTC (rev 7202)
+++ core/trunk/src/test/resources/log4j.xml 2008-11-26 20:52:40 UTC (rev 7203)
@@ -46,13 +46,19 @@
<!-- ================ -->
<category name="org.jboss.cache">
- <priority value="ERROR"/>
+ <priority value="WARN"/>
</category>
+ <!-- these two are in separate sections since they
+ make a lot of noise in DEBUG or TRACE -->
<category name="org.jboss.cache.factories">
<priority value="WARN"/>
</category>
+ <category name="org.jboss.cache.jmx">
+ <priority value="WARN"/>
+ </category>
+
<category name="org.jboss.tm">
<priority value="WARN"/>
</category>
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7202 - core/trunk/src/main/docbook/faq/en.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-26 15:39:47 -0500 (Wed, 26 Nov 2008)
New Revision: 7202
Modified:
core/trunk/src/main/docbook/faq/en/master.xml
Log:
JBCACHE-1444 ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name
Modified: core/trunk/src/main/docbook/faq/en/master.xml
===================================================================
--- core/trunk/src/main/docbook/faq/en/master.xml 2008-11-26 20:35:07 UTC (rev 7201)
+++ core/trunk/src/main/docbook/faq/en/master.xml 2008-11-26 20:39:47 UTC (rev 7202)
@@ -1,800 +1,868 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
- "../../../../docbook-support/support/docbook-dtd/docbookx.dtd"
- >
+ "../../../../docbook-support/support/docbook-dtd/docbookx.dtd"
+ >
<book lang="en">
- <bookinfo>
- <title>Frequently Asked Questions about JBoss Cache</title>
- <!-- Release version and date -->
- <releaseinfo>Release 3.0.0 Naga</releaseinfo>
- <pubdate>October 2008</pubdate>
+ <bookinfo>
+ <title>Frequently Asked Questions about JBoss Cache</title>
+ <!-- Release version and date -->
+ <releaseinfo>Release 3.0.0 Naga</releaseinfo>
+ <pubdate>October 2008</pubdate>
- <author>
- <firstname>Manik</firstname>
- <surname>Surtani</surname>
- <email>manik AT jboss DOT org</email>
- </author>
+ <author>
+ <firstname>Manik</firstname>
+ <surname>Surtani</surname>
+ <email>manik AT jboss DOT org</email>
+ </author>
- <author>
- <firstname>Ben</firstname>
- <surname>Wang</surname>
- <email>ben DOT wang AT jboss DOT com</email>
- </author>
+ <author>
+ <firstname>Ben</firstname>
+ <surname>Wang</surname>
+ <email>ben DOT wang AT jboss DOT com</email>
+ </author>
- <author>
- <firstname>Bela</firstname>
- <surname>Ban</surname>
- <email>bela AT jboss DOT com</email>
- </author>
+ <author>
+ <firstname>Bela</firstname>
+ <surname>Ban</surname>
+ <email>bela AT jboss DOT com</email>
+ </author>
- <author>
- <firstname>Scott</firstname>
- <surname>Marlow</surname>
- <email>smarlow AT novell DOT com</email>
- </author>
+ <author>
+ <firstname>Scott</firstname>
+ <surname>Marlow</surname>
+ <email>smarlow AT novell DOT com</email>
+ </author>
- <author>
- <firstname>Galder</firstname>
- <surname>Zamarreño</surname>
- <email>galder DOT zamarreno AT jboss DOT com</email>
- </author>
+ <author>
+ <firstname>Galder</firstname>
+ <surname>Zamarreño</surname>
+ <email>galder DOT zamarreno AT jboss DOT com</email>
+ </author>
- <abstract>
- <para>This is a compilation of the most frequently asked
- questions about JBoss Cache. Please report any bugs,
- inconsistencies, or omissions you find in this FAQ on the
- <ulink url="http://www.jboss.org/jbosscache">JBoss Cache User Forum</ulink>.
- </para>
- <para>
- This FAQ is divided into specific sections, all pertaining to the core JBoss Cache library. POJO Cache has a
- separate FAQ
- document pertaining to POJO Cache specifics.
- </para>
- </abstract>
+ <abstract>
+ <para>This is a compilation of the most frequently asked
+ questions about JBoss Cache. Please report any bugs,
+ inconsistencies, or omissions you find in this FAQ on the
+ <ulink url="http://www.jboss.org/jbosscache">JBoss Cache User Forum</ulink>.
+ </para>
+ <para>
+ This FAQ is divided into specific sections, all pertaining to the core JBoss Cache library. POJO Cache
+ has a
+ separate FAQ
+ document pertaining to POJO Cache specifics.
+ </para>
+ </abstract>
- <!-- copyright info -->
- <copyright>
- <year>2005</year>
- <year>2006</year>
- <year>2007</year>
- <year>2008</year>
- <holder>JBoss, a division of Red Hat Inc., and all authors as named.</holder>
- </copyright>
- </bookinfo>
+ <!-- copyright info -->
+ <copyright>
+ <year>2005</year>
+ <year>2006</year>
+ <year>2007</year>
+ <year>2008</year>
+ <holder>JBoss, a division of Red Hat Inc., and all authors as named.</holder>
+ </copyright>
+ </bookinfo>
- <chapter id="general">
- <title>General Information</title>
- <qandaset>
+ <chapter id="general">
+ <title>General Information</title>
+ <qandaset>
- <qandaentry>
- <question>
- <para>What is JBoss Cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>What is JBoss Cache?</para>
+ </question>
- <answer>
- <para>JBoss Cache is a replicated and transactional cache. It is
- replicated since multiple JBoss Cache instances can be distributed
- (either within the same JVM or across several JVMs whether they reside on
- the same machine or on different machines on a network) and data is
- replicated across the whole group. It is transactional because a
- user can configure a
- <ulink url="http://java.sun.com/products/jta/">JTA</ulink>
- compliant transaction
- manager and make any cache
- interaction transactional, and caches would participate in ongoing JTA transactions. Note that the cache can also be run without
- any replication; this is the local mode.
- </para>
+ <answer>
+ <para>JBoss Cache is a replicated and transactional cache. It is
+ replicated since multiple JBoss Cache instances can be distributed
+ (either within the same JVM or across several JVMs whether they reside on
+ the same machine or on different machines on a network) and data is
+ replicated across the whole group. It is transactional because a
+ user can configure a
+ <ulink url="http://java.sun.com/products/jta/">JTA</ulink>
+ compliant transaction
+ manager and make any cache
+ interaction transactional, and caches would participate in ongoing JTA transactions. Note that
+ the cache can also be run without
+ any replication; this is the local mode.
+ </para>
- <para>JBoss Cache comes in two flavours: Core and POJO versions. The core library
- (using the <literal>org.jboss.cache.Cache</literal>
- interface) is the underlying library that organises data in a tree-like structure and handles all locking,
- passivation,
- eviction and replication characteristics of data in the cache. The POJO library (using the
- <literal>org.jboss.cache.pojo.PojoCache</literal> interface) is built atop the core library and allows introspection
- of objects in the cache providing transparent coherence by using JBoss AOP. Note that the POJO edition
- of JBoss Cache
- (often referred to as POJO Cache) comes with a separate set of documentation (Users' Guide, FAQ, etc.)
- available on the JBoss Cache
- <ulink url="http://www.jboss.org/jbosscache/">documentation website</ulink>.
- </para>
+ <para>JBoss Cache comes in two flavours: Core and POJO versions. The core library
+ (using the
+ <literal>org.jboss.cache.Cache</literal>
+ interface) is the underlying library that organises data in a tree-like structure and handles
+ all locking,
+ passivation,
+ eviction and replication characteristics of data in the cache. The POJO library (using the
+ <literal>org.jboss.cache.pojo.PojoCache</literal>
+ interface) is built atop the core library and allows introspection
+ of objects in the cache providing transparent coherence by using JBoss AOP. Note that the POJO
+ edition
+ of JBoss Cache
+ (often referred to as POJO Cache) comes with a separate set of documentation (Users' Guide, FAQ,
+ etc.)
+ available on the JBoss Cache
+ <ulink url="http://www.jboss.org/jbosscache/">documentation website</ulink>.
+ </para>
- <para>
- JBoss Cache is made available in one of four different packages:
- <itemizedlist>
- <listitem>
- <para>
- <literal>jbosscache-core</literal>
- </para>
- contains the core Cache library for users who do not wish to use the additional functionality
- offered by POJO Cache.
- </listitem>
- <listitem>
- <para>
- <literal>jbosscache-pojo</literal>
- </para>
- contains the core Cache library as well as POJO Cache extensions and dependencies.
- </listitem>
- </itemizedlist>
- </para>
- </answer>
- </qandaentry>
+ <para>
+ JBoss Cache is made available in one of four different packages:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>jbosscache-core</literal>
+ </para>
+ contains the core Cache library for users who do not wish to use the additional
+ functionality
+ offered by POJO Cache.
+ </listitem>
+ <listitem>
+ <para>
+ <literal>jbosscache-pojo</literal>
+ </para>
+ contains the core Cache library as well as POJO Cache extensions and dependencies.
+ </listitem>
+ </itemizedlist>
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Who are the JBoss Cache developers?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Who are the JBoss Cache developers?</para>
+ </question>
- <answer>
- <para>
- JBoss Cache has an active community of developers and contributors. The project was founded by Bela
- Ban
- and is currently led by Manik Surtani. Jason Greene is the lead for the POJO Cache subsystem, and other
- contributors both past and present include Ben Wang, Harald Gliebe, Brian Stansberry, Vladimir
- Blagojevic, Mircea Markus, Jimmy Wilson, Galder Zamarreño and Elias Ross.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ JBoss Cache has an active community of developers and contributors. The project was founded by
+ Bela
+ Ban
+ and is currently led by Manik Surtani. Jason Greene is the lead for the POJO Cache subsystem,
+ and other
+ contributors both past and present include Ben Wang, Harald Gliebe, Brian Stansberry, Vladimir
+ Blagojevic, Mircea Markus, Jimmy Wilson, Galder Zamarreño and Elias Ross.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>What about licensing?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>What about licensing?</para>
+ </question>
- <answer>
- <para>JBoss Cache is licensed under
- <ulink url="http://www.gnu.org/licenses/lgpl.html">LGPL</ulink>, an <ulink url="http://www.opensource.org/">OSI</ulink>-approved open source license.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>JBoss Cache is licensed under
+ <ulink url="http://www.gnu.org/licenses/lgpl.html">LGPL</ulink>, an<ulink
+ url="http://www.opensource.org/">OSI</ulink>-approved open source license.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Where can I download JBoss Cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Where can I download JBoss Cache?</para>
+ </question>
- <answer>
- <para>The JBoss Cache
- <ulink url="http://www.jboss.com/products/jbosscache/downloads">product download page</ulink>
- has prebuilt binaries as well as source distributions. You can also grab snapshots from the JBoss.org subversion
- repository. See
- <ulink url="http://www.jboss.org/community/docs/DOC-10259">the JBoss Cache development</ulink>
- wiki page for details.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>The JBoss Cache
+ <ulink url="http://www.jboss.com/products/jbosscache/downloads">product download page</ulink>
+ has prebuilt binaries as well as source distributions. You can also grab snapshots from the
+ JBoss.org subversion
+ repository. See
+ <ulink url="http://www.jboss.org/community/docs/DOC-10259">the JBoss Cache development</ulink>
+ wiki page for details.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How do I build JBoss Cache from sources?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How do I build JBoss Cache from sources?</para>
+ </question>
- <answer>
- <para>
- Read the README-Maven.txt file in the source root. Note that you will need a JDK >= 5.0, and Apache Maven >= 2.0.6.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ Read the README-Maven.txt file in the source root. Note that you will need a JDK >= 5.0, and
+ Apache Maven >= 2.0.6.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Which versions of the JDK are supported by JBoss Cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Which versions of the JDK are supported by JBoss Cache?</para>
+ </question>
- <answer>
- <para>
- JBoss Cache is baselined on Java 5 and is tested on Java 5 and 6 VMs. If, for whatever reason you have
- to use Java 1.4, you could build a retroweaved version of the core cache
- library that is Java 1.4 compatible, using the simple instructions on this wiki page
- <ulink url="http://www.jboss.org/community/docs/DOC-10263">on building and running JBoss Cache on Java 1.4.
- </ulink>.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ JBoss Cache is baselined on Java 5 and is tested on Java 5 and 6 VMs. If, for whatever reason
+ you have
+ to use Java 1.4, you could build a retroweaved version of the core cache
+ library that is Java 1.4 compatible, using the simple instructions on this wiki page
+ <ulink url="http://www.jboss.org/community/docs/DOC-10263">on building and running JBoss Cache
+ on Java 1.4.
+ </ulink>.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How do I know the version of JBoss Cache that I am using?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How do I know the version of JBoss Cache that I am using?</para>
+ </question>
- <answer>
- <para>
- <literal>java -jar jbosscache-core.jar</literal>
- will spit out version details.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ <literal>java -jar jbosscache-core.jar</literal>
+ will spit out version details.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I run JBoss Cache outside of JBoss Application
- Server?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can I run JBoss Cache outside of JBoss Application
+ Server?
+ </para>
+ </question>
- <answer>
- <para>
- Absolutely! Even though JBoss Cache comes integrated with JBoss Application Server,
- it can also be used in any other Java EE server such as BEA WebLogic, IBM Websphere or Tomcat. It
- can also run in a standalone Java process, completely outside of an application server. See the Users' Guide for more
- details.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ Absolutely! Even though JBoss Cache comes integrated with JBoss Application Server,
+ it can also be used in any other Java EE server such as BEA WebLogic, IBM Websphere or Tomcat.
+ It
+ can also run in a standalone Java process, completely outside of an application server. See the
+ Users' Guide for more
+ details.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How can I migrate my application and configuration from using JBoss Cache 1.x to 2.x?</para>
- </question>
- <answer>
- <para>Look at
- <ulink url="http://www.jboss.org/community/docs/DOC-10246">this wiki page</ulink>
- for help.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>How can I migrate my application and configuration from using JBoss Cache 1.x to 2.x?</para>
+ </question>
+ <answer>
+ <para>Look at
+ <ulink url="http://www.jboss.org/community/docs/DOC-10246">this wiki page</ulink>
+ for help.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>What about from 2.x to 3.x?</para>
- </question>
- <answer>
- <para>
- JBoss Cache 3.x is API compatible with 2.x, although as far as possible you should refactor your code
- not to use deprecated methods as these may disappear in future releases of JBoss Cache.
- </para>
- <para>
- JBoss Cache 3.x comes with an all new configuration format. Old 2.x configuration files will still
- work, although you will get a warning in the logs about this. Again, as far as possible, we recommend
- migrating your configuration file to the new format. Scripts are provided with the JBoss Cache 3.x
- distribution to migrate configuration files (see <literal>config2to3.sh</literal> and <literal>config2to3.bat</literal>).
- </para>
- <para>
- Note that to take advantage of some of the new features in JBoss Cache 3.x, you need to be using the
- new configuration format.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>What about from 2.x to 3.x?</para>
+ </question>
+ <answer>
+ <para>
+ JBoss Cache 3.x is API compatible with 2.x, although as far as possible you should refactor your
+ code
+ not to use deprecated methods as these may disappear in future releases of JBoss Cache.
+ </para>
+ <para>
+ JBoss Cache 3.x comes with an all new configuration format. Old 2.x configuration files will
+ still
+ work, although you will get a warning in the logs about this. Again, as far as possible, we
+ recommend
+ migrating your configuration file to the new format. Scripts are provided with the JBoss Cache
+ 3.x
+ distribution to migrate configuration files (see
+ <literal>config2to3.sh</literal>
+ and<literal>config2to3.bat</literal>).
+ </para>
+ <para>
+ Note that to take advantage of some of the new features in JBoss Cache 3.x, you need to be using
+ the
+ new configuration format.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Where can I report bugs or problems?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Where can I report bugs or problems?</para>
+ </question>
- <answer>
- <para>Please report any bugs or problems to
- <ulink url="http://www.jboss.org/jbosscache">JBoss Cache User Forum</ulink>.
- </para>
- </answer>
- </qandaentry>
- </qandaset>
- </chapter>
+ <answer>
+ <para>Please report any bugs or problems to
+ <ulink url="http://www.jboss.org/jbosscache">JBoss Cache User Forum</ulink>.
+ </para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </chapter>
- <chapter id="TreeCache">
- <title>JBoss Cache - Core</title>
+ <chapter id="TreeCache">
+ <title>JBoss Cache - Core</title>
- <qandaset>
+ <qandaset>
- <qandaentry>
- <question>
- <para>Using JBoss Cache 2 or 3 on JBoss AS 4.x</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Using JBoss Cache 2 or 3 on JBoss AS 4.x</para>
+ </question>
- <answer>
- <para>
- JBoss AS 4.x ships with JBoss Cache 1.4.x. To make use of new features, performance improvements
- and bug fixes in newer releases, you can follow some of the steps outlined on <ulink url="http://www.jboss.org/community/docs/DOC-10254">this wiki page</ulink>.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ JBoss AS 4.x ships with JBoss Cache 1.4.x. To make use of new features, performance improvements
+ and bug fixes in newer releases, you can follow some of the steps outlined on<ulink
+ url="http://www.jboss.org/community/docs/DOC-10254">this wiki page</ulink>.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I run multiple JBoss Cache instances on the same VM?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can I run multiple JBoss Cache instances on the same VM?</para>
+ </question>
- <answer>
- <para>Yes. There are some scenarios where you may want to run
- multiple instances of JBoss Cache. For example, you want to run
- multiple local cache instances with each instance having its own
- configuration (e.g., different cache policy). In this case, you will
- need multiple xml configuration files.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. There are some scenarios where you may want to run
+ multiple instances of JBoss Cache. For example, you want to run
+ multiple local cache instances with each instance having its own
+ configuration (e.g., different cache policy). In this case, you will
+ need multiple xml configuration files.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can JBoss Cache run as a second level cache inside
- Hibernate?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can JBoss Cache run as a second level cache inside
+ Hibernate?
+ </para>
+ </question>
- <answer>
- <para>Yes. Since Hibernate 3.0 release, you can configure it to use
- JBoss Cache as a second level cache. For details,
- see Hibernate documentation, and also see
- <ulink url="http://www.jboss.org/community/docs/DOC-10265">this wiki page</ulink>.
- </para>
- <para>
- JBoss Cache 3.x with MVCC in particular works very well as a Hibernate second level cache.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. Since Hibernate 3.0 release, you can configure it to use
+ JBoss Cache as a second level cache. For details,
+ see Hibernate documentation, and also see
+ <ulink url="http://www.jboss.org/community/docs/DOC-10265">this wiki page</ulink>.
+ </para>
+ <para>
+ JBoss Cache 3.x with MVCC in particular works very well as a Hibernate second level cache.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>What about using POJO Cache as a Hibernate cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>What about using POJO Cache as a Hibernate cache?</para>
+ </question>
- <answer>
- <para>It is not necessary to use POJO Cache for second level
- cache inside Hibernate because Hibernate
- manages fine-grained fields in Java objects. Using POJO Cache won't
- provide any advantage, and will be an unnecessary performance drawback.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>It is not necessary to use POJO Cache for second level
+ cache inside Hibernate because Hibernate
+ manages fine-grained fields in Java objects. Using POJO Cache won't
+ provide any advantage, and will be an unnecessary performance drawback.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How can I configure JBoss Cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How can I configure JBoss Cache?</para>
+ </question>
- <answer>
- <para>You can configure the JBoss Cache through a configuration xml
- file or programmatically using a
- <literal>org.jboss.cache.config.Configuration</literal>
- object, passed in to the
- <literal>org.jboss.cache.CacheFactory</literal>
- instance.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>You can configure the JBoss Cache through a configuration xml
+ file or programmatically using a
+ <literal>org.jboss.cache.config.Configuration</literal>
+ object, passed in to the
+ <literal>org.jboss.cache.CacheFactory</literal>
+ instance.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I use a schema or DTD to validate my JBoss Cache configuration file?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can I use a schema or DTD to validate my JBoss Cache configuration file?
+ </para>
+ </question>
- <answer>
- <para>
- As of JBoss Cache 3.x, yes. An XSD schema is provided in your jbosscache-core.jar file, and is also
- available online, on <ulink url="http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd">http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd</ulink>.
- You can configure your IDE, text editor or XML authoring tool to use this schema to validate your file.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ As of JBoss Cache 3.x, yes. An XSD schema is provided in your jbosscache-core.jar file, and is
+ also
+ available online, on<ulink url="http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd">
+ http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd</ulink>.
+ You can configure your IDE, text editor or XML authoring tool to use this schema to validate
+ your file.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>What is the difference between the different cache modes?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>What is the difference between the different cache modes?
+ </para>
+ </question>
- <answer>
- <para>JBossCache has five different cache modes, i.e.,
- <literal>LOCAL</literal>
- ,
- <literal>REPL_SYNC</literal>
- ,
- <literal>REPL_ASYNC</literal>
- ,
- <literal>INVALIDATION_SYNC</literal>
- and
- <literal>INVALIDATION_ASYNC</literal>
- . If you want to run JBoss Cache as a
- single instance, then you should set the cache mode to
- <literal>LOCAL</literal>
- so that it won't attempt to replicate anything.
- If you want to have synchronous replication among different
- JBoss Cache instances, you set it to
- <literal>REPL_SYNC</literal>
- .
- For asynchronous replication, use
- <literal>AYSNC_REPL</literal>
- . If you do not wish to replicate cached data but simply inform other caches in a cluster that data
- under
- specific addresses are now stale and should be evicted from memory, use
- <literal>INVALIDATION_SYNC</literal>
- or
- <literal>INVALIDTAION_ASYNC</literal>
- . Synchronous and asynchronous behavior applies to invalidation as well as replication.
- </para>
+ <answer>
+ <para>JBossCache has five different cache modes, i.e.,
+ <literal>LOCAL</literal>
+ ,
+ <literal>REPL_SYNC</literal>
+ ,
+ <literal>REPL_ASYNC</literal>
+ ,
+ <literal>INVALIDATION_SYNC</literal>
+ and
+ <literal>INVALIDATION_ASYNC</literal>
+ . If you want to run JBoss Cache as a
+ single instance, then you should set the cache mode to
+ <literal>LOCAL</literal>
+ so that it won't attempt to replicate anything.
+ If you want to have synchronous replication among different
+ JBoss Cache instances, you set it to
+ <literal>REPL_SYNC</literal>
+ .
+ For asynchronous replication, use
+ <literal>AYSNC_REPL</literal>
+ . If you do not wish to replicate cached data but simply inform other caches in a cluster that
+ data
+ under
+ specific addresses are now stale and should be evicted from memory, use
+ <literal>INVALIDATION_SYNC</literal>
+ or
+ <literal>INVALIDTAION_ASYNC</literal>
+ . Synchronous and asynchronous behavior applies to invalidation as well as replication.
+ </para>
- <para>Note that
- <literal>ASYNC_REPL</literal>
- and
- <literal>INVALIDATION_ASYNC</literal>
- are non-blocking. This
- can be useful when you want to have another JBoss Cache serving as a
- mirror or backup and you don't want to wait for confirmation that this mirror has received your
- messages.
- </para>
- </answer>
- </qandaentry>
+ <para>Note that
+ <literal>ASYNC_REPL</literal>
+ and
+ <literal>INVALIDATION_ASYNC</literal>
+ are non-blocking. This
+ can be useful when you want to have another JBoss Cache serving as a
+ mirror or backup and you don't want to wait for confirmation that this mirror has received your
+ messages.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How does JBoss Cache's replication mechanism work?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How does JBoss Cache's replication mechanism work?</para>
+ </question>
- <answer>
- <para>JBoss Cache leverages
- <ulink url="http://www.jgroups.org">JGroups</ulink>
- for network communications. A JGroups configuration section is present in your JBoss Cache configuration.
- </para>
- <para>
- A user
- can configure the cluster of JBoss Cache instances by sharing the
- same cluster name (
- <literal>cluster name</literal>
- ). There is also
- an option of whether to populate the cache data upon starting a new
- instance in the
- <literal>ClusterConfig</literal>
- attribute.
- </para>
+ <answer>
+ <para>JBoss Cache leverages
+ <ulink url="http://www.jgroups.org">JGroups</ulink>
+ for network communications. A JGroups configuration section is present in your JBoss Cache
+ configuration.
+ </para>
+ <para>
+ A user
+ can configure the cluster of JBoss Cache instances by sharing the
+ same cluster name (
+ <literal>cluster name</literal>
+ ). There is also
+ an option of whether to populate the cache data upon starting a new
+ instance in the
+ <literal>ClusterConfig</literal>
+ attribute.
+ </para>
- <para>Note that once all instances join the same replication group,
- every replication change is propagated to all participating members.
- There is no mechanism for sub-partitioning where some replication
- can be done within only a subset of members, unless you use the Buddy Replication features. See the
- Users' Guide for more details on this.
- </para>
- </answer>
- </qandaentry>
+ <para>Note that once all instances join the same replication group,
+ every replication change is propagated to all participating members.
+ There is no mechanism for sub-partitioning where some replication
+ can be done within only a subset of members, unless you use the Buddy Replication features. See
+ the
+ Users' Guide for more details on this.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>I run a 2 node cluster. If the network dies, do the caches continue to run?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>I run a 2 node cluster. If the network dies, do the caches continue to run?</para>
+ </question>
- <answer>
- <para>Yes, both will continue to run, but depending on your replication mode, all transactions or
- operations may not complete. If
- <literal>REPL_SYNC</literal>
- is used, operations will fail while if
- <literal>REPL_ASYNC</literal>
- is used they will succeed. Even if they succeed though, caches will be out of sync.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes, both will continue to run, but depending on your replication mode, all transactions or
+ operations may not complete. If
+ <literal>REPL_SYNC</literal>
+ is used, operations will fail while if
+ <literal>REPL_ASYNC</literal>
+ is used they will succeed. Even if they succeed though, caches will be out of sync.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I plug in library X instead of JGroups to handle remote calls and group communications?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can I plug in library X instead of JGroups to handle remote calls and group communications?
+ </para>
+ </question>
- <answer>
- <para>At this stage the answer is no. We do have an abstraction layer between the
- communication suite and JBoss Cache in the pipelines, and this may appear as a feature at some stage
- in
- the future.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>At this stage the answer is no. We do have an abstraction layer between the
+ communication suite and JBoss Cache in the pipelines, and this may appear as a feature at some
+ stage
+ in
+ the future.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Does the cache need to replicate to every other instance in the cluster? Isn't this slow if the
- cluster is large?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Does the cache need to replicate to every other instance in the cluster? Isn't this slow if
+ the
+ cluster is large?
+ </para>
+ </question>
- <answer>
- <para>Replication need not occur to every node in the cluster. This feature -
- called Buddy Replication -
- allows each node to pick one or more 'buddies' in the cluster and only replicate to its buddies. This
- allows a cluster to scale
- very easily with no extra impact on memory or network traffic with each node added.
- </para>
- <para>
- See the Users' Guide for more information on Buddy Replication, and how it can be used to achieve very
- high
- scalability.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Replication need not occur to every node in the cluster. This feature -
+ called Buddy Replication -
+ allows each node to pick one or more 'buddies' in the cluster and only replicate to its buddies.
+ This
+ allows a cluster to scale
+ very easily with no extra impact on memory or network traffic with each node added.
+ </para>
+ <para>
+ See the Users' Guide for more information on Buddy Replication, and how it can be used to
+ achieve very
+ high
+ scalability.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question><para>I'm using Buddy Replication. Do I need to have some form of session affinity?</para></question>
- <answer><para>Session affinity relates to returning to the same cache instance for the same data being used.
- While this is strictly not a requirement for Buddy Replication, it is greatly recommended to minimize
- moving state around a cluster.</para></answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>I'm using Buddy Replication. Do I need to have some form of session affinity?</para>
+ </question>
+ <answer>
+ <para>Session affinity relates to returning to the same cache instance for the same data being used.
+ While this is strictly not a requirement for Buddy Replication, it is greatly recommended to
+ minimize
+ moving state around a cluster.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>If I have the need for different configuration properties (e.g.,
- <literal>CacheMode</literal>
- and
- <literal>IsolationLevel</literal>
- ), do I simply need to create multiple
- <literal>org.jboss.cache.Cache</literal>
- instances with the appropriate configuration?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>If I have the need for different configuration properties (e.g.,
+ <literal>CacheMode</literal>
+ and
+ <literal>IsolationLevel</literal>
+ ), do I simply need to create multiple
+ <literal>org.jboss.cache.Cache</literal>
+ instances with the appropriate configuration?
+ </para>
+ </question>
- <answer>
- <para>Yes. All the above mentioned properties are per cache
- instance. Therefore you will need separate
- <literal>org.jboss.cache.Cache</literal>
- instances.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. All the above mentioned properties are per cache
+ instance. Therefore you will need separate
+ <literal>org.jboss.cache.Cache</literal>
+ instances.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Isn't this expensive from a networking standpoint, i.e., needing to create sockets for each
- <literal>org.jboss.cache.Cache</literal>
- instance?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Isn't this expensive from a networking standpoint, i.e., needing to create sockets for each
+ <literal>org.jboss.cache.Cache</literal>
+ instance?
+ </para>
+ </question>
- <answer>
- <para>
- Yes, it can be. For such cases it is recommended that you configure your cache using the JGroups
- Multiplexer, which allows several caches to share
- a single JGroups channel. Please see the Users' Guide for details on how to configure the JGroups
- Multiplexer.
- </para>
- <para>
- A faster and more efficient approach is to use a shared transport in JGroups. Please see
- <ulink url="http://www.jgroups.org">the JGroups documentation</ulink> for more details on how to do this.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ Yes, it can be. For such cases it is recommended that you configure your cache using the JGroups
+ Multiplexer, which allows several caches to share
+ a single JGroups channel. Please see the Users' Guide for details on how to configure the
+ JGroups
+ Multiplexer.
+ </para>
+ <para>
+ A faster and more efficient approach is to use a shared transport in JGroups. Please see
+ <ulink url="http://www.jgroups.org">the JGroups documentation</ulink>
+ for more details on how to do this.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Does the
- <literal>ClusterName</literal>
- configuration element have
- any relation to the JBoss AS cluster
- <literal>PartitionName</literal>
- ?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Does the
+ <literal>ClusterName</literal>
+ configuration element have
+ any relation to the JBoss AS cluster
+ <literal>PartitionName</literal>
+ ?
+ </para>
+ </question>
- <answer>
- <para>Yes. They are both JGroups group names. Besides the notion of
- a channel in JGroups, it also can partition the channel into different
- group names.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. They are both JGroups group names. Besides the notion of
+ a channel in JGroups, it also can partition the channel into different
+ group names.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>When using multiple JGroups based components
- [cluster-service.xml, cache (multiple instances)], what is the
- correct/valid way to configure those components to make sure my
- multicast addresses don't conflict?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>When using multiple JGroups based components
+ [cluster-service.xml, cache (multiple instances)], what is the
+ correct/valid way to configure those components to make sure my
+ multicast addresses don't conflict?
+ </para>
+ </question>
- <answer>
- <para>There are two parameters to consider: multicast address (plus
- port) and the group name. At minimum, you will have to run
- components using a different group name. But whether to run them on
- the same channel depends upon whether the communication performance
- is critical for you or not. If it is, then it'd be best to run them
- on different channels.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>There are two parameters to consider: multicast address (plus
+ port) and the group name. At minimum, you will have to run
+ components using a different group name. But whether to run them on
+ the same channel depends upon whether the communication performance
+ is critical for you or not. If it is, then it'd be best to run them
+ on different channels.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Does JBoss Cache support cache persistence
- storage?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support cache persistence
+ storage?
+ </para>
+ </question>
- <answer>
- <para>Yes. JBoss Cache has a cache loader
- interface that supports cache persistence. See below for more FAQs on cache loaders.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. JBoss Cache has a cache loader
+ interface that supports cache persistence. See below for more FAQs on cache loaders.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Does JBoss Cache support cache passivation/ overflow
- to a data store?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support cache passivation/ overflow
+ to a data store?
+ </para>
+ </question>
- <answer>
- <para>Yes. JBoss Cache uses the
- cache loader to support cache passivation/ overflow. See
- documentation on how to configure and use this feature.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. JBoss Cache uses the
+ cache loader to support cache passivation/ overflow. See
+ documentation on how to configure and use this feature.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Is JBoss Cache thread safe?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Is JBoss Cache thread safe?</para>
+ </question>
- <answer>
- <para>Yes, it is thread safe.</para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes, it is thread safe.</para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Does JBoss Cache support XA (2PC) transactions now?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support XA (2PC) transactions now?</para>
+ </question>
- <answer>
- <para>No, although it is also on our to do list. Our internal
- implementation does use a procedure similar to 2PC to coordinate a
- transactions among different instances, but JBoss Cache is not an XA resource.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>No, although it is also on our to do list. Our internal
+ implementation does use a procedure similar to 2PC to coordinate a
+ transactions among different instances, but JBoss Cache is not an XA resource.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Which transaction managers are supported by
- JBoss Cache?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Which transaction managers are supported by
+ JBoss Cache?
+ </para>
+ </question>
- <answer>
- <para>JBoss Cache supports any TransactionManager that is
- <ulink url="http://java.sun.com/products/jta/">JTA</ulink>
- compliant such as <ulink url="http://www.jboss.org/jbosstm/">JBoss Transactions</ulink>.
- </para>
- <para>
- While JBoss Cache does ships with a
- dummy transaction manager
- (<literal>org.jboss.cache.transaction.DummyTransactionManager</literal>), we do <emphasis>not</emphasis>
- recommend using this for production. It is not thread safe, and is intended for internal testing only.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>JBoss Cache supports any TransactionManager that is
+ <ulink url="http://java.sun.com/products/jta/">JTA</ulink>
+ compliant such as<ulink url="http://www.jboss.org/jbosstm/">JBoss Transactions</ulink>.
+ </para>
+ <para>
+ While JBoss Cache does ships with a
+ dummy transaction manager
+ (<literal>org.jboss.cache.transaction.DummyTransactionManager</literal>), we do
+ <emphasis>not</emphasis>
+ recommend using this for production. It is not thread safe, and is intended for internal testing
+ only.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How do I set up the cache to be transactional?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How do I set up the cache to be transactional?</para>
+ </question>
- <answer>
- <para>You either use the default transaction manager that ships with JBoss AS
- or you have to implement the
- <literal>org.jboss.cache.transaction.TransactionManagerLookup</literal>
- interface, and return an
- instance of your
- <literal>javax.transaction.TransactionManager</literal>
- implementation. The
- configuration property
- <literal>TransactionManagerLookupClass</literal>
- defines the class
- to be used by the cache to fetch a reference to a
- transaction manager. It is trivial to implement this interface to support
- other transaction managers. Once this attribute is specified, the
- cache will look up the transaction context from this transaction
- manager.
- </para>
- <para>
- The <literal>org.jboss.cache.transaction.GenericTransactionManagerLookup</literal> class that ships
- with JBoss Cache is able to detect and bind to most popular transaction managers. See the <literal>GenericTransactionManagerLookup</literal>
- javadocs for more information.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>You either use the default transaction manager that ships with JBoss AS
+ or you have to implement the
+ <literal>org.jboss.cache.transaction.TransactionManagerLookup</literal>
+ interface, and return an
+ instance of your
+ <literal>javax.transaction.TransactionManager</literal>
+ implementation. The
+ configuration property
+ <literal>TransactionManagerLookupClass</literal>
+ defines the class
+ to be used by the cache to fetch a reference to a
+ transaction manager. It is trivial to implement this interface to support
+ other transaction managers. Once this attribute is specified, the
+ cache will look up the transaction context from this transaction
+ manager.
+ </para>
+ <para>
+ The
+ <literal>org.jboss.cache.transaction.GenericTransactionManagerLookup</literal>
+ class that ships
+ with JBoss Cache is able to detect and bind to most popular transaction managers. See the
+ <literal>GenericTransactionManagerLookup</literal>
+ javadocs for more information.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How do I control the cache locking level?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How do I control the cache locking level?</para>
+ </question>
- <answer>
- <para>JBoss Cache lets you control the cache locking level through
- the transaction isolation level. This is configured through the
- attribute
- <literal>IsolationLevel</literal>
- . The transaction
- isolation levels correspond to database
- isolation levels, namely,
- <literal>NONE</literal>
- ,
- <literal>READ_UNCOMMITTED</literal>
- ,
- <literal>READ_COMMITTED</literal>
- ,
- <literal>REPEATABLE_READ</literal>
- , and
- <literal>SERIALIZABLE</literal>
- . Note that these isolation levels are ignored if optimistic locking is used. For details, please
- refer
- to the
- user manual.
- </para>
- <para>
- As of JBoss Cache 3.x, when using the MVCC locking scheme, only <literal>READ_COMMITTED</literal> and
- <literal>REPEATABLE_READ</literal> are supported. Any other isolation level provided will either be upgraded
- or downgraded accordingly.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>JBoss Cache lets you control the cache locking level through
+ the transaction isolation level. This is configured through the
+ attribute
+ <literal>IsolationLevel</literal>
+ . The transaction
+ isolation levels correspond to database
+ isolation levels, namely,
+ <literal>NONE</literal>
+ ,
+ <literal>READ_UNCOMMITTED</literal>
+ ,
+ <literal>READ_COMMITTED</literal>
+ ,
+ <literal>REPEATABLE_READ</literal>
+ , and
+ <literal>SERIALIZABLE</literal>
+ . Note that these isolation levels are ignored if optimistic locking is used. For details,
+ please
+ refer
+ to the
+ user manual.
+ </para>
+ <para>
+ As of JBoss Cache 3.x, when using the MVCC locking scheme, only
+ <literal>READ_COMMITTED</literal>
+ and
+ <literal>REPEATABLE_READ</literal>
+ are supported. Any other isolation level provided will either be upgraded
+ or downgraded accordingly.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How does JBoss Cache lock data for concurrent access?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How does JBoss Cache lock data for concurrent access?</para>
+ </question>
- <answer>
- <para>In JBoss Cache 2.x, by default pessimistic locking is used to lock data nodes, based on the isolation level
- configured. We also offer optimistic locking to allow for greater concurrency
- at
- the cost of slight processing overhead and performance. See the documentation for a more detailed
- discussion on concurrency and locking in JBoss Cache.
- </para>
- <para>
- In JBoss Cache 3.x, optimistic and pessimistic locking are deprecated in favour of MVCC (multi-version concurrency
- control), which is far more efficient than either optimistic or pessimistic locking. For a detailed discussion on
- our MVCC implementation, see <ulink url="http://jbosscache.blogspot.com/2008/07/mvcc-has-landed.html">this blog entry</ulink> and <ulink url="http://www.jboss.org/community/docs/DOC-10272">this wiki page</ulink>.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>In JBoss Cache 2.x, by default pessimistic locking is used to lock data nodes, based on the
+ isolation level
+ configured. We also offer optimistic locking to allow for greater concurrency
+ at
+ the cost of slight processing overhead and performance. See the documentation for a more
+ detailed
+ discussion on concurrency and locking in JBoss Cache.
+ </para>
+ <para>
+ In JBoss Cache 3.x, optimistic and pessimistic locking are deprecated in favour of MVCC
+ (multi-version concurrency
+ control), which is far more efficient than either optimistic or pessimistic locking. For a
+ detailed discussion on
+ our MVCC implementation, see
+ <ulink url="http://jbosscache.blogspot.com/2008/07/mvcc-has-landed.html">this blog entry</ulink>
+ and<ulink url="http://www.jboss.org/community/docs/DOC-10272">this wiki page</ulink>.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How do I enable Optimistic Locking or MVCC in JBoss Cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How do I enable Optimistic Locking or MVCC in JBoss Cache?</para>
+ </question>
- <answer>
- <para>
- Please see the configuration section of the Users' Guide for details.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ Please see the configuration section of the Users' Guide for details.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I use the cache locking level even without a transaction
- context?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can I use the cache locking level even without a transaction
+ context?
+ </para>
+ </question>
- <answer>
- <para>Yes. JBoss Cache controls the individual node locking behavior
- through the isolation level semantics. This means even if you don't
- use a transaction, you can specify the lock level via isolation
- level. You can think of the node locking behavior outside of a
- transaction as if it is under transaction with
- <literal>auto_commit</literal>
- on.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. JBoss Cache controls the individual node locking behavior
+ through the isolation level semantics. This means even if you don't
+ use a transaction, you can specify the lock level via isolation
+ level. You can think of the node locking behavior outside of a
+ transaction as if it is under transaction with
+ <literal>auto_commit</literal>
+ on.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>
- Does JBoss Cache support <literal>SELECT FOR UPDATE</literal> semantics?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>
+ Does JBoss Cache support
+ <literal>SELECT FOR UPDATE</literal>
+ semantics?
+ </para>
+ </question>
- <answer>
- <para>
- Yes, but this is is only possible if you are running within a JTA transaction <emphasis>and</emphasis>
- are using either <literal>MVCC</literal> or <literal>PESSIMISTIC</literal> as your node locking scheme.
- </para>
- <para>
- To achieve <literal>SELECT FOR UPDATE</literal> semantics, simply do:
- </para>
- <programlisting role="JAVA"><![CDATA[
+ <answer>
+ <para>
+ Yes, but this is is only possible if you are running within a JTA transaction
+ <emphasis>and</emphasis>
+ are using either
+ <literal>MVCC</literal>
+ or
+ <literal>PESSIMISTIC</literal>
+ as your node locking scheme.
+ </para>
+ <para>
+ To achieve
+ <literal>SELECT FOR UPDATE</literal>
+ semantics, simply do:
+ </para>
+ <programlisting role="JAVA"><![CDATA[
// start transaction ...
@@ -806,630 +874,689 @@
// end transaction
]]></programlisting>
- </answer>
- </qandaentry>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>With replication (REPL_SYNC/REPL_ASYNC) or invalidation (INVALIDATION_SYNC/INVALIDATION_ASYNC), how
- often does the cache broadcast messages over the network?
- </para>
- </question>
+ <qandaentry>
+ <question>
+ <para>With replication (REPL_SYNC/REPL_ASYNC) or invalidation
+ (INVALIDATION_SYNC/INVALIDATION_ASYNC), how
+ often does the cache broadcast messages over the network?
+ </para>
+ </question>
- <answer>
- <para>If the updates are under transaction, then the broadcasts
- happen only when the transaction is about to commit (actually
- during the prepare stage internally). That is, it will be a batch
- update. However, if the operations are not under transaction
- context, then each update will trigger replication. Note that this
- has performance implications if network latency is a problem.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>If the updates are under transaction, then the broadcasts
+ happen only when the transaction is about to commit (actually
+ during the prepare stage internally). That is, it will be a batch
+ update. However, if the operations are not under transaction
+ context, then each update will trigger replication. Note that this
+ has performance implications if network latency is a problem.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>How can I do a mass removal?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>How can I do a mass removal?</para>
+ </question>
- <answer>
- <para>If you do a <literal>cache.removeNode("/myroot")</literal>, it will recursively remove
- all the entries under "/myroot".
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>If you do a<literal>cache.removeNode("/myroot")</literal>, it will recursively remove
+ all the entries under "/myroot".
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I monitor and manage the JBoss Cache?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>Can I monitor and manage the JBoss Cache?</para>
+ </question>
- <answer>
- <para>Yes, using a JMX console such as the one shipped with JBoss AS or Java 5's
- <literal>jconsole</literal>
- utility. See the chapter titled
- <emphasis role="bold">Management Information</emphasis>
- in the JBoss Cache Users' Guide for more details.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes, using a JMX console such as the one shipped with JBoss AS or Java 5's
+ <literal>jconsole</literal>
+ utility. See the chapter titled
+ <emphasis role="bold">Management Information</emphasis>
+ in the JBoss Cache Users' Guide for more details.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>Can I disable JBoss Cache management attributes?</para>
- </question>
+ <qandaentry>
+ <question>
+ <para>
+ JBoss Cache uses a
+ <literal>:</literal>
+ character in its object name. This causes problems with
+ my MBean server. What can I do about it?
+ </para>
+ </question>
+ <answer>
+ <para>
+ This is something we have seen with some MBean servers. By default, JBoss Cache uses
+ <literal>jboss.cache:service=JBossCache</literal>
+ as a prefix to all objects it binds in JMX.
+ To work around this, use the
+ <literal>-Djbosscache.jmx.prefix</literal>
+ JVM parameter to pass in
+ an alternate prefix.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes, you can. See the section on configuration in the JBoss Cache Users' Guide.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Can I disable JBoss Cache management attributes?</para>
+ </question>
- <qandaentry>
- <question>
- <para>What happened to jboss-serialization.jar?</para>
- </question>
+ <answer>
+ <para>Yes, you can. See the section on configuration in the JBoss Cache Users' Guide.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>
- As of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of the
- benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0 is
- baselined on Java 5, there was no need to provide these benefits separately.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>What happened to jboss-serialization.jar?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Does JBoss Cache support partitioning?</para>
- </question>
+ <answer>
+ <para>
+ As of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of
+ the
+ benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0 is
+ baselined on Java 5, there was no need to provide these benefits separately.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Not right now. JBoss Cache does not support partitioning that a
- user can configure to have different set of data residing on
- different cache instances while still participating as a replication
- group.
- </para>
- <para>
- This is on the roadmap though, so do keep an eye on <ulink url="http://jira.jboss.org/jira/browse/JBCACHE-60">JBCACHE-60</ulink> if you are interested.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support partitioning?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Does JBoss Cache handle the concept of application classloading
- inside, say, a Java EE container?
- </para>
- </question>
+ <answer>
+ <para>Not right now. JBoss Cache does not support partitioning that a
+ user can configure to have different set of data residing on
+ different cache instances while still participating as a replication
+ group.
+ </para>
+ <para>
+ This is on the roadmap though, so do keep an eye on
+ <ulink url="http://jira.jboss.org/jira/browse/JBCACHE-60">JBCACHE-60</ulink>
+ if you are interested.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Application-specific classloading is used widely inside a Java EE
- container. For example, a web application may require a new
- classloader to scope a specific version of the user library.
- However, by default JBoss Cache is agnostic to the classloader. In
- general, this leads to two kinds of problems:
- </para>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache handle the concept of application classloading
+ inside, say, a Java EE container?
+ </para>
+ </question>
- <itemizedlist>
- <listitem>
- <para>Object instance is stored in cache1 and replicated to
- cache2. As a result, the instance in cache2 is created by the
- system classloader. The replication may fail if the system
- classloader on cache2 does not have access to the required
- class. Even if replication doesn't fail, a user thread in cache2
- may not be able to access the object if the user thread is
- expecting a type defined by the application classloader.
- </para>
- </listitem>
+ <answer>
+ <para>Application-specific classloading is used widely inside a Java EE
+ container. For example, a web application may require a new
+ classloader to scope a specific version of the user library.
+ However, by default JBoss Cache is agnostic to the classloader. In
+ general, this leads to two kinds of problems:
+ </para>
- <listitem>
- <para>Object instance is created by thread 1 and will be
- accessed by thread 2 (with two different classloaders).
- JBoss Cache has no notion of the different classloaders involved.
- As a result, you will have a
- <literal>ClassCastException</literal>
- . This is a standard
- problem in passing an object from one application space to
- another; JBoss Cache just adds a level of indirection in passing
- the object.
- </para>
- </listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>Object instance is stored in cache1 and replicated to
+ cache2. As a result, the instance in cache2 is created by the
+ system classloader. The replication may fail if the system
+ classloader on cache2 does not have access to the required
+ class. Even if replication doesn't fail, a user thread in cache2
+ may not be able to access the object if the user thread is
+ expecting a type defined by the application classloader.
+ </para>
+ </listitem>
- <para>To solve the first kind of issue JBoss Cache uses a
- <literal>CacheMarshaller</literal>
- .
- Basically, this allows application code to register a classloader
- with a portion of the cache tree for use in handling objects
- replicated to that portion. See the
- <literal>CacheMarshaller</literal>
- section of
- the Users' Guide for more details.
- </para>
+ <listitem>
+ <para>Object instance is created by thread 1 and will be
+ accessed by thread 2 (with two different classloaders).
+ JBoss Cache has no notion of the different classloaders involved.
+ As a result, you will have a
+ <literal>ClassCastException</literal>
+ . This is a standard
+ problem in passing an object from one application space to
+ another; JBoss Cache just adds a level of indirection in passing
+ the object.
+ </para>
+ </listitem>
+ </itemizedlist>
- <para>To solve the second kind of issue, you can use the the <literal>UseLazyDeserialization</literal> configuration
- option in JBoss Cache, which wraps your objects in a <literal>Marshalledvalue</literal> wrapper. The <literal>MarshalledValue</literal>
- serializes and deserializes your object on demand, ensuring the proper thread local context class loader is used each time.
- </para>
- </answer>
- </qandaentry>
+ <para>To solve the first kind of issue JBoss Cache uses a
+ <literal>CacheMarshaller</literal>
+ .
+ Basically, this allows application code to register a classloader
+ with a portion of the cache tree for use in handling objects
+ replicated to that portion. See the
+ <literal>CacheMarshaller</literal>
+ section of
+ the Users' Guide for more details.
+ </para>
- <qandaentry>
- <question>
- <para>Does JBoss Cache currently support pre-event and post-event
- notification?
- </para>
- </question>
+ <para>To solve the second kind of issue, you can use the the
+ <literal>UseLazyDeserialization</literal>
+ configuration
+ option in JBoss Cache, which wraps your objects in a
+ <literal>Marshalledvalue</literal>
+ wrapper. The
+ <literal>MarshalledValue</literal>
+ serializes and deserializes your object on demand, ensuring the proper thread local context
+ class loader is used each time.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes. A boolean is passed in to each notification callback identifying whether the callback is
- before
- or after the event. See the
- <literal>org.jboss.cache.notifications.annotations.CacheListener</literal>
- annotation for details.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache currently support pre-event and post-event
+ notification?
+ </para>
+ </question>
- <qandaentry>
- <question>
- <para>How do I implement a custom listener to listen to
- cache events?
- </para>
- </question>
+ <answer>
+ <para>Yes. A boolean is passed in to each notification callback identifying whether the callback is
+ before
+ or after the event. See the
+ <literal>org.jboss.cache.notifications.annotations.CacheListener</literal>
+ annotation for details.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>
- See the Users' Guide on this subject.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>How do I implement a custom listener to listen to
+ cache events?
+ </para>
+ </question>
- <qandaentry>
- <question>
- <para>Can I use
- <literal>UseRegionBasedMarshalling</literal>
- attribute in JBoss Cache in order to get
- around ClassCastExceptions happening when accessing data in the cache that has just been redeployed?
- </para>
- </question>
+ <answer>
+ <para>
+ See the Users' Guide on this subject.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes, you can. Originally, cache Marshalling was designed as a
- workaround for those replicated caches that upon state transfer did not have access to the
- classloaders defining the objects in the cache.
- </para>
+ <qandaentry>
+ <question>
+ <para>Can I use
+ <literal>UseRegionBasedMarshalling</literal>
+ attribute in JBoss Cache in order to get
+ around ClassCastExceptions happening when accessing data in the cache that has just been
+ redeployed?
+ </para>
+ </question>
- <para>On each deployment, JBoss creates a new classloader per the top level deployment artifact, for
- example an EAR. You also have to bear in mind that a class in an application server is defined not
- only by the class name but also its classloader. So, assuming that the cache is not deployed as part
- of your deployment, you could deploy an application and put instances of classes belonging to this
- deployment inside the cache. If you did a redeployment and try to do a get operation of the data
- previously put, this would result on a ClassCastException. This is because even though the class names
- are the same, the class definitions are not. The current classloader is different to the one when
- the classes were originally put.
- </para>
+ <answer>
+ <para>Yes, you can. Originally, cache Marshalling was designed as a
+ workaround for those replicated caches that upon state transfer did not have access to the
+ classloaders defining the objects in the cache.
+ </para>
- <para>By enabling marshalling, you can control the lifecycle of the data in the cache and if on
- undeployment, you deactivate the region and unregister the classloader that you'd have registered on
- deployment, you'd evict the data in the cache locally. That means that in the next deployment, the
- data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to get
- around this problem is only recommended when you have some kind of persistence backing where the data
- survives, for example using CacheLoaders, or when JBoss Cache is used as a second level cache in a
- persistence framework.
- </para>
+ <para>On each deployment, JBoss creates a new classloader per the top level deployment artifact, for
+ example an EAR. You also have to bear in mind that a class in an application server is defined
+ not
+ only by the class name but also its classloader. So, assuming that the cache is not deployed as
+ part
+ of your deployment, you could deploy an application and put instances of classes belonging to
+ this
+ deployment inside the cache. If you did a redeployment and try to do a get operation of the data
+ previously put, this would result on a ClassCastException. This is because even though the class
+ names
+ are the same, the class definitions are not. The current classloader is different to the one
+ when
+ the classes were originally put.
+ </para>
- <para>To implement this feature, please follow the instructions indicated in the example located
- in the CacheMarshaller section of the Users' Guide. It's worth noting that instead of a
- <literal>ServletContextListener</literal>
- , you could add this code into an
- <literal>MBean</literal>
- that contained lifecycle methods, such as
- <literal>start()</literal>
- and
- <literal>stop()</literal>
- .
- The key would be for this MBean to depend on the target cache, so that it can operate as long as the
- cache is up and running.
- </para>
- </answer>
- </qandaentry>
+ <para>By enabling marshalling, you can control the lifecycle of the data in the cache and if on
+ undeployment, you deactivate the region and unregister the classloader that you'd have
+ registered on
+ deployment, you'd evict the data in the cache locally. That means that in the next deployment,
+ the
+ data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to get
+ around this problem is only recommended when you have some kind of persistence backing where the
+ data
+ survives, for example using CacheLoaders, or when JBoss Cache is used as a second level cache in
+ a
+ persistence framework.
+ </para>
- </qandaset>
- </chapter>
+ <para>To implement this feature, please follow the instructions indicated in the example located
+ in the CacheMarshaller section of the Users' Guide. It's worth noting that instead of a
+ <literal>ServletContextListener</literal>
+ , you could add this code into an
+ <literal>MBean</literal>
+ that contained lifecycle methods, such as
+ <literal>start()</literal>
+ and
+ <literal>stop()</literal>
+ .
+ The key would be for this MBean to depend on the target cache, so that it can operate as long as
+ the
+ cache is up and running.
+ </para>
+ </answer>
+ </qandaentry>
- <chapter id="eviction">
- <title>Eviction Policies</title>
- <qandaset>
- <qandaentry>
- <question>
- <para>Does JBoss Cache support eviction policies?</para>
- </question>
+ </qandaset>
+ </chapter>
- <answer>
- <para>Yes. JBoss Cache currently supports multiple eviction policies such as LRU, MRU, and FIFO.
- Users can also plug in their own eviction policy algorithms. See user
- guide for details.
- </para>
- </answer>
- </qandaentry>
+ <chapter id="eviction">
+ <title>Eviction Policies</title>
+ <qandaset>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support eviction policies?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Does JBoss Cache's eviction policy operates in
- replication mode?
- </para>
- </question>
+ <answer>
+ <para>Yes. JBoss Cache currently supports multiple eviction policies such as LRU, MRU, and FIFO.
+ Users can also plug in their own eviction policy algorithms. See user
+ guide for details.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes and no. :-)</para>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache's eviction policy operates in
+ replication mode?
+ </para>
+ </question>
- <para>The eviction policy only operates in local mode. That is, nodes are
- only evicted locally. This may cause the cache contents not to be
- synchronized temporarily. But when a user tries to obtain the cached
- contents of an evicted node and finds out that is null (e.g.,
- <literal>get</literal>
- returns null), it should get it from the
- other data source and re-populate the data in the cache. During this
- moment, the node content will be propagated and the cache content
- will be in sync.
- </para>
+ <answer>
+ <para>Yes and no. :-)</para>
- <para>However, you still can run eviction policies with cache mode
- set to either
- <literal>REPL_SYNC</literal>
- or
- <literal>REPL_ASYNC</literal>
- . Depending on your use case, you can
- set multiple cache instances to have their own eviction policy
- (which are applied locally) or just have selected instances with
- eviction policies activated.
- </para>
+ <para>The eviction policy only operates in local mode. That is, nodes are
+ only evicted locally. This may cause the cache contents not to be
+ synchronized temporarily. But when a user tries to obtain the cached
+ contents of an evicted node and finds out that is null (e.g.,
+ <literal>get</literal>
+ returns null), it should get it from the
+ other data source and re-populate the data in the cache. During this
+ moment, the node content will be propagated and the cache content
+ will be in sync.
+ </para>
- <para>Also note that, with cache loader option, a locally evicted
- node can also be persisted to the backend store and a user can
- retrieve it from the store later on.
- </para>
- </answer>
- </qandaentry>
+ <para>However, you still can run eviction policies with cache mode
+ set to either
+ <literal>REPL_SYNC</literal>
+ or
+ <literal>REPL_ASYNC</literal>
+ . Depending on your use case, you can
+ set multiple cache instances to have their own eviction policy
+ (which are applied locally) or just have selected instances with
+ eviction policies activated.
+ </para>
- <qandaentry>
- <question>
- <para>Does JBoss Cache support
- <literal>Region</literal>
- ?
- </para>
- </question>
+ <para>Also note that, with cache loader option, a locally evicted
+ node can also be persisted to the backend store and a user can
+ retrieve it from the store later on.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes. JBoss Cache has the notion of region where a user can
- configure the eviction policy parameters (e.g.,
- <literal>maxNodes</literal>
- or
- <literal>timeToIdleSeconds</literal>
- )
- </para>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support
+ <literal>Region</literal>
+ ?
+ </para>
+ </question>
- <para>A region in JBoss Cache denotes a portion of tree hierarchy,
- e.g., a fully qualified name (
- <literal>org.jboss.cache.Fqn</literal>
- ). For example,
- a user can define
- <literal>/org/jboss</literal>
- and
- <literal>/org/foocom</literal>
- as two separate regions. But note
- that you can configure the region programmatically now, i.e.,
- everything has to be configured through the xml file.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>Yes. JBoss Cache has the notion of region where a user can
+ configure the eviction policy parameters (e.g.,
+ <literal>maxNodes</literal>
+ or
+ <literal>timeToIdleSeconds</literal>
+ )
+ </para>
- <qandaentry>
- <question>
- <para>I have turned on the eviction policy, why do I still get "out
- of memory" (OOM) exception?
- </para>
- </question>
+ <para>A region in JBoss Cache denotes a portion of tree hierarchy,
+ e.g., a fully qualified name (
+ <literal>org.jboss.cache.Fqn</literal>
+ ). For example,
+ a user can define
+ <literal>/org/jboss</literal>
+ and
+ <literal>/org/foocom</literal>
+ as two separate regions. But note
+ that you can configure the region programmatically now, i.e.,
+ everything has to be configured through the xml file.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>OOM can happen when the speed of cache access exceeds the
- speed of eviction policy handling timer. Eviction policy handler
- will wake up every
- <literal>wakeUpInterval</literal> milliseconds (or <literal>wakeUpIntervalSeconds</literal> seconds, prior to 3.x)
- to process the eviction event queue. So when the queue size is full, it will create a
- backlog and cause out-of-memory exceptions to happen unless the eviction timer catches
- up. To address this problem, in addition to increase the VM heap
- size, you can also reduce the
- <literal>wakeUpInterval</literal>
- so the timer thread
- processes the queue more frequently.
- </para>
- </answer>
- </qandaentry>
- </qandaset>
- </chapter>
- <chapter id="cacheloaders">
- <title>Cache Loaders</title>
- <qandaset>
+ <qandaentry>
+ <question>
+ <para>I have turned on the eviction policy, why do I still get "out
+ of memory" (OOM) exception?
+ </para>
+ </question>
+ <answer>
+ <para>OOM can happen when the speed of cache access exceeds the
+ speed of eviction policy handling timer. Eviction policy handler
+ will wake up every
+ <literal>wakeUpInterval</literal>
+ milliseconds (or
+ <literal>wakeUpIntervalSeconds</literal>
+ seconds, prior to 3.x)
+ to process the eviction event queue. So when the queue size is full, it will create a
+ backlog and cause out-of-memory exceptions to happen unless the eviction timer catches
+ up. To address this problem, in addition to increase the VM heap
+ size, you can also reduce the
+ <literal>wakeUpInterval</literal>
+ so the timer thread
+ processes the queue more frequently.
+ </para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </chapter>
+ <chapter id="cacheloaders">
+ <title>Cache Loaders</title>
+ <qandaset>
- <qandaentry>
- <question>
- <para>What is a cache loader?</para>
- </question>
- <answer>
- <para>A cache loader is the connection of JBoss Cache to a
- (persistent) data store. The cache loader is called by JBoss Cache to
- fetch data from a store when that data is not in the cache, and when
- modifications are made to data in the cache the Cache Loader is
- called to store those modifications back to the store.
- </para>
+ <qandaentry>
+ <question>
+ <para>What is a cache loader?</para>
+ </question>
- <para>In conjunction with eviction policies, JBoss Cache with a
- cache loader allows a user to maintain a bounded cache for a large
- backend datastore. Frequently used data is fetched from the
- datastore into the cache, and the least used data is evicted, in
- order to provide fast access to frequently accessed data. This is
- all configured through XML, and the programmer doesn't have to take
- care of loading and eviction.
- </para>
+ <answer>
+ <para>A cache loader is the connection of JBoss Cache to a
+ (persistent) data store. The cache loader is called by JBoss Cache to
+ fetch data from a store when that data is not in the cache, and when
+ modifications are made to data in the cache the Cache Loader is
+ called to store those modifications back to the store.
+ </para>
- <para>JBoss Cache currently ships with several cache loader
- implementations, including:
- </para>
+ <para>In conjunction with eviction policies, JBoss Cache with a
+ cache loader allows a user to maintain a bounded cache for a large
+ backend datastore. Frequently used data is fetched from the
+ datastore into the cache, and the least used data is evicted, in
+ order to provide fast access to frequently accessed data. This is
+ all configured through XML, and the programmer doesn't have to take
+ care of loading and eviction.
+ </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <literal>org.jboss.cache.loader.FileCacheLoader</literal>
- : this implementation uses the file
- system to store and retrieve data. JBoss Cache nodes are mapped
- to directories, subnodes to subdirectories etc. Attributes of
- a node are mapped to a data file
- inside the
- directory.
- </para>
- </listitem>
+ <para>JBoss Cache currently ships with several cache loader
+ implementations, including:
+ </para>
- <listitem>
- <para>
- <literal>org.jboss.cache.loader.jdbm.JdbmCacheLoader</literal>
- : this implementation is based on <ulink url="http://jdbm.sourceforge.net/">JDBM</ulink>,
- an open source file-based transactional persistence engine.
- </para>
- </listitem>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>org.jboss.cache.loader.FileCacheLoader</literal>
+ : this implementation uses the file
+ system to store and retrieve data. JBoss Cache nodes are mapped
+ to directories, subnodes to subdirectories etc. Attributes of
+ a node are mapped to a data file
+ inside the
+ directory.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>org.jboss.cache.loader.bdbje.BdbjeCacheLoader</literal>
- : this implementation is based on the
- Oracle's Berkeley DB Java Edition database, a fast and efficient
- transactional database. It uses a single file for the entire
- store. Note that if you use the Berkeley DB cache loader with
- JBoss Cache and wish to ship your product, you will have to acquire a
- <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from Oracle</ulink>.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>org.jboss.cache.loader.jdbm.JdbmCacheLoader</literal>
+ : this implementation is based on<ulink url="http://jdbm.sourceforge.net/">
+ JDBM</ulink>,
+ an open source file-based transactional persistence engine.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>org.jboss.cache.loader.JDBCCacheLoader</literal>
- : this implementation uses the relational database as the persistent
- storage.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>org.jboss.cache.loader.bdbje.BdbjeCacheLoader</literal>
+ : this implementation is based on the
+ Oracle's Berkeley DB Java Edition database, a fast and efficient
+ transactional database. It uses a single file for the entire
+ store. Note that if you use the Berkeley DB cache loader with
+ JBoss Cache and wish to ship your product, you will have to acquire a
+ <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from
+ Oracle</ulink>.
+ </para>
+ </listitem>
- <listitem>
- <para>And more. See the chapter on cache loaders in the Users' Guide for more details.</para>
- </listitem>
- </itemizedlist>
- </para>
- </answer>
- </qandaentry>
+ <listitem>
+ <para>
+ <literal>org.jboss.cache.loader.JDBCCacheLoader</literal>
+ : this implementation uses the relational database as the persistent
+ storage.
+ </para>
+ </listitem>
- <qandaentry>
- <question>
- <para>Is the FileCacheLoader recommended for production use?</para>
- </question>
+ <listitem>
+ <para>And more. See the chapter on cache loaders in the Users' Guide for more details.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>
- No, it is not. The FileCacheLoader has some severe limitations which restrict its use in a production
- environment, or if used in such an environment, it should be used with due care and sufficient
- understanding of these limitations.
- <itemizedlist>
- <listitem>Due to the way the FileCacheLoader represents a tree structure on disk (directories and
- files) traversal is inefficient for deep trees.
- </listitem>
- <listitem>Usage on shared filesystems like NFS, Windows shares, etc. should be avoided as these do
- not implement proper file locking and can cause data corruption.
- </listitem>
- <listitem>Usage with an isolation level of NONE can cause corrupt writes as multiple threads
- attempt to write to the same file.
- </listitem>
- <listitem>File systems are inherently not transactional, so when attempting to use your cache in a
- transactional context, failures when writing to the file (which happens during the commit phase)
- cannot be recovered.
- </listitem>
- </itemizedlist>
+ <qandaentry>
+ <question>
+ <para>Is the FileCacheLoader recommended for production use?</para>
+ </question>
- As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly concurrent,
- transactional or stressful environment, and its use is restricted to testing.
- </para>
- </answer>
- </qandaentry>
+ <answer>
+ <para>
+ No, it is not. The FileCacheLoader has some severe limitations which restrict its use in a
+ production
+ environment, or if used in such an environment, it should be used with due care and sufficient
+ understanding of these limitations.
+ <itemizedlist>
+ <listitem>Due to the way the FileCacheLoader represents a tree structure on disk
+ (directories and
+ files) traversal is inefficient for deep trees.
+ </listitem>
+ <listitem>Usage on shared filesystems like NFS, Windows shares, etc. should be avoided as
+ these do
+ not implement proper file locking and can cause data corruption.
+ </listitem>
+ <listitem>Usage with an isolation level of NONE can cause corrupt writes as multiple threads
+ attempt to write to the same file.
+ </listitem>
+ <listitem>File systems are inherently not transactional, so when attempting to use your
+ cache in a
+ transactional context, failures when writing to the file (which happens during the
+ commit phase)
+ cannot be recovered.
+ </listitem>
+ </itemizedlist>
- <qandaentry>
- <question>
- <para>Can writing to cache loaders be asynchronous?</para>
- </question>
+ As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly
+ concurrent,
+ transactional or stressful environment, and its use is restricted to testing.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes. Set the
- <literal>async</literal>
- attrobute to true. See the JBoss Cache Users' Guide for a more
- detailed discussion. By default though, all cache loader writes are
- synchronous and will block.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Can writing to cache loaders be asynchronous?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Can I write my own cache loader ?</para>
- </question>
+ <answer>
+ <para>Yes. Set the
+ <literal>async</literal>
+ attrobute to true. See the JBoss Cache Users' Guide for a more
+ detailed discussion. By default though, all cache loader writes are
+ synchronous and will block.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes. A cache loader is a class implementing
- <literal>org.jboss.cache.loader.CacheLoader</literal>
- or extending
- <literal>org.jboss.cache.loader.AbstractCacheLoader</literal>
- . It is
- configured via the XML file (see JBoss Cache Users' Guide).
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Can I write my own cache loader ?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Does a cache loader have to use a persistent store ?</para>
- </question>
+ <answer>
+ <para>Yes. A cache loader is a class implementing
+ <literal>org.jboss.cache.loader.CacheLoader</literal>
+ or extending
+ <literal>org.jboss.cache.loader.AbstractCacheLoader</literal>
+ . It is
+ configured via the XML file (see JBoss Cache Users' Guide).
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>No, a cache loader could for example fetch (and possibly store)
- its data from a webdav-capable webserver. Another example is a
- caching proxy server, which fetches contents from the web. Note that
- an implementation of CacheLoader may not implement the 'store'
- functionality in this case, but just the 'load'
- functionality.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Does a cache loader have to use a persistent store ?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Do I have to pay to use Oracle's Berkeley DB CacheLoader?</para>
- </question>
+ <answer>
+ <para>No, a cache loader could for example fetch (and possibly store)
+ its data from a webdav-capable webserver. Another example is a
+ caching proxy server, which fetches contents from the web. Note that
+ an implementation of CacheLoader may not implement the 'store'
+ functionality in this case, but just the 'load'
+ functionality.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Not if you use it only for personal use. As soon as you
- distribute your product with BdbjeCacheLoader, you have to purchase
- a commercial license from Oracle. See details at
- <ulink
- url="http://www.sleepycat.com/jeforjbosscache">http://www.sleepycat.com/jeforjbosscache
- </ulink>
- .
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Do I have to pay to use Oracle's Berkeley DB CacheLoader?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Are there any tools available to monitor the Berkeley DB instance?</para>
- </question>
+ <answer>
+ <para>Not if you use it only for personal use. As soon as you
+ distribute your product with BdbjeCacheLoader, you have to purchase
+ a commercial license from Oracle. See details at
+ <ulink
+ url="http://www.sleepycat.com/jeforjbosscache">http://www.sleepycat.com/jeforjbosscache
+ </ulink>
+ .
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>
- Yes. Oracle ships a JMX-based monitoring tool, called
- <ulink
- url="http://www.oracle.com/technology/documentation/berkeley-db/je/java/com/sl...">
- JEMonitor
- </ulink>
- which can be downloaded from the Oracle website.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Are there any tools available to monitor the Berkeley DB instance?</para>
+ </question>
- <qandaentry>
- <question>
- <para>When tuning my Berkeley DB instance, where should I put my je.properties file?</para>
- </question>
+ <answer>
+ <para>
+ Yes. Oracle ships a JMX-based monitoring tool, called
+ <ulink
+ url="http://www.oracle.com/technology/documentation/berkeley-db/je/java/com/sl...">
+ JEMonitor
+ </ulink>
+ which can be downloaded from the Oracle website.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>
- <literal>je.properties</literal>
- should reside in your Berkeley DB home directory. This is the directory you pass
- in to the BDBJECacheLoader's
- <literal>location</literal>
- configuration property.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>When tuning my Berkeley DB instance, where should I put my je.properties file?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Can I use more than one cache loader?</para>
- </question>
+ <answer>
+ <para>
+ <literal>je.properties</literal>
+ should reside in your Berkeley DB home directory. This is the directory you pass
+ in to the BDBJECacheLoader's
+ <literal>location</literal>
+ configuration property.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes. Within the CacheLoaderConfiguration XML
- element (see Users' Guide chapter on cache loaders) you can
- describe several cache loaders. The impact is that the cache will
- look at all of the cache loaders in the order they've been
- configured, until it finds a valid, non-null element of data. When
- performing writes, all cache loaders are written to (except if the
- ignoreModifications element has been set to true for a specific
- cache loader.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Can I use more than one cache loader?</para>
+ </question>
- <qandaentry>
- <question>
- <para>Can I migrate a JDBCacheLoader or FileCacheLoader based cache store containing data formatted with
- JBoss Cache 1.x.x to JBoss Cache 2.0 format?
- </para>
- </question>
+ <answer>
+ <para>Yes. Within the CacheLoaderConfiguration XML
+ element (see Users' Guide chapter on cache loaders) you can
+ describe several cache loaders. The impact is that the cache will
+ look at all of the cache loaders in the order they've been
+ configured, until it finds a valid, non-null element of data. When
+ performing writes, all cache loaders are written to (except if the
+ ignoreModifications element has been set to true for a specific
+ cache loader.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>Yes. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in the
- JBoss Cache Users' Guide.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Can I migrate a JDBCacheLoader or FileCacheLoader based cache store containing data formatted
+ with
+ JBoss Cache 1.x.x to JBoss Cache 2.0 format?
+ </para>
+ </question>
- <qandaentry>
- <question>
- <para>
- Is the TCPDelegatingCacheLoader resilient to TCPCacheServer restarts?
- </para>
- </question>
+ <answer>
+ <para>Yes. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in
+ the
+ JBoss Cache Users' Guide.
+ </para>
+ </answer>
+ </qandaentry>
- <answer>
- <para>
- As of JBoss Cache 2.1.0, the answer is yes. See the Users' Guide for details on how to configure and
- tune
- your retries and wait period for reestablishing the TCP connection.
- </para>
- <para>
- Prior to that, restarting the TCPCacheServer would also mean
- restarting your application that uses the cache.
- </para>
- </answer>
- </qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Is the TCPDelegatingCacheLoader resilient to TCPCacheServer restarts?
+ </para>
+ </question>
- </qandaset>
- </chapter>
- <chapter id="troubleshooting">
- <title>Troubleshooting</title>
- <qandaset>
+ <answer>
+ <para>
+ As of JBoss Cache 2.1.0, the answer is yes. See the Users' Guide for details on how to configure
+ and
+ tune
+ your retries and wait period for reestablishing the TCP connection.
+ </para>
+ <para>
+ Prior to that, restarting the TCPCacheServer would also mean
+ restarting your application that uses the cache.
+ </para>
+ </answer>
+ </qandaentry>
- <qandaentry>
- <question>
- <para>I am having problems getting JBoss Cache to work, where can I get information on troubleshooting?
- </para>
- </question>
- <answer>
- <para>Troubleshooting section can be found in the following
- <ulink url="http://www.jboss.org/community/docs/DOC-10288">wiki link</ulink>
- .
- </para>
- </answer>
- </qandaentry>
- </qandaset>
- </chapter>
+ </qandaset>
+ </chapter>
+ <chapter id="troubleshooting">
+ <title>Troubleshooting</title>
+ <qandaset>
+
+ <qandaentry>
+ <question>
+ <para>I am having problems getting JBoss Cache to work, where can I get information on
+ troubleshooting?
+ </para>
+ </question>
+ <answer>
+ <para>Troubleshooting section can be found in the following
+ <ulink url="http://www.jboss.org/community/docs/DOC-10288">wiki link</ulink>
+ .
+ </para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </chapter>
</book>
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7201 - core/trunk/src/main/java/org/jboss/cache/jmx.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-26 15:35:07 -0500 (Wed, 26 Nov 2008)
New Revision: 7201
Modified:
core/trunk/src/main/java/org/jboss/cache/jmx/JmxRegistrationManager.java
Log:
JBCACHE-1444 ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name
Modified: core/trunk/src/main/java/org/jboss/cache/jmx/JmxRegistrationManager.java
===================================================================
--- core/trunk/src/main/java/org/jboss/cache/jmx/JmxRegistrationManager.java 2008-11-26 20:27:59 UTC (rev 7200)
+++ core/trunk/src/main/java/org/jboss/cache/jmx/JmxRegistrationManager.java 2008-11-26 20:35:07 UTC (rev 7201)
@@ -29,7 +29,10 @@
import org.jboss.cache.config.Configuration;
import org.jboss.cache.factories.ComponentRegistry;
-import javax.management.*;
+import javax.management.InstanceAlreadyExistsException;
+import javax.management.MBeanServer;
+import javax.management.MalformedObjectNameException;
+import javax.management.ObjectName;
import java.lang.management.ManagementFactory;
import java.util.ArrayList;
import java.util.List;
@@ -42,23 +45,34 @@
* is being used.
* <p/>
* It is immutable: both cache instance and MBeanServer are being passed as arguments to the constructor.
+ * <p />
+ * <p>
+ * Note that by default object names used are prefixed with <tt>jboss.cache:service=JBossCache</tt>. While this format
+ * works for and is consistent with JBoss AS and the JMX console, it has been known to cause problems with other JMX
+ * servers such as Websphere. To work around this, you can provide the following VM system property to override this
+ * prefix with a prefix of your choice:
+ * <tt><b>-Djbosscache.jmx.prefix=JBossCache</b></tt>
+ * </p>
*
* @author Mircea.Markus(a)jboss.com
* @since 3.0
*/
public class JmxRegistrationManager
{
+
private static final Log log = LogFactory.getLog(JmxRegistrationManager.class);
+ private static final String GENERAL_PREFIX = System.getProperty("jbosscache.jmx.prefix", "jboss.cache:service=JBossCache");
+
/**
* default ObjectName for clusterd caches. Cluster name should pe appended.
*/
- public static final String REPLICATED_CACHE_PREFIX = "jboss.cache:service=JBossCache,cluster=";
+ public static final String REPLICATED_CACHE_PREFIX = GENERAL_PREFIX + ",cluster=";
/**
* default ObjectName for non clustered caches. An unique identifier should be appended.
*/
- public static final String LOCAL_CACHE_PREFIX = "jboss.cache:service=JBossCache,uniqueId=";
+ public static final String LOCAL_CACHE_PREFIX = GENERAL_PREFIX + ",uniqueId=";
/**
* Key for every Dynamic mbean added.
@@ -198,7 +212,7 @@
return;
}
if (cacheSpi.getConfiguration().getCacheMode().equals(Configuration.CacheMode.LOCAL))
- {
+ {
// CurrentTimeMillis is not good enaugh as an unique id generator. I am constantly
// getting conflicts in several parallel tests on my box. Maybe some more sofisticated
// unique id generator should be provided?
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7200 - in core/trunk/src/main/java/org/jboss/cache/loader: jdbm and 1 other directory.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-26 15:27:59 -0500 (Wed, 26 Nov 2008)
New Revision: 7200
Modified:
core/trunk/src/main/java/org/jboss/cache/loader/bdbje/BdbjeCacheLoader.java
core/trunk/src/main/java/org/jboss/cache/loader/jdbm/JdbmCacheLoader.java
Log:
JBCACHE-1448 Jdbm and BDBJE cache loader incorrectly reading database name from location String
Modified: core/trunk/src/main/java/org/jboss/cache/loader/bdbje/BdbjeCacheLoader.java
===================================================================
--- core/trunk/src/main/java/org/jboss/cache/loader/bdbje/BdbjeCacheLoader.java 2008-11-26 20:16:12 UTC (rev 7199)
+++ core/trunk/src/main/java/org/jboss/cache/loader/bdbje/BdbjeCacheLoader.java 2008-11-26 20:27:59 UTC (rev 7200)
@@ -26,26 +26,16 @@
import com.sleepycat.bind.tuple.TupleBinding;
import com.sleepycat.bind.tuple.TupleInput;
import com.sleepycat.bind.tuple.TupleOutput;
-import com.sleepycat.je.Cursor;
-import com.sleepycat.je.Database;
-import com.sleepycat.je.DatabaseConfig;
-import com.sleepycat.je.DatabaseEntry;
-import com.sleepycat.je.DeadlockException;
-import com.sleepycat.je.Environment;
-import com.sleepycat.je.EnvironmentConfig;
-import com.sleepycat.je.JEVersion;
-import com.sleepycat.je.LockMode;
-import com.sleepycat.je.OperationStatus;
-import com.sleepycat.je.Transaction;
+import com.sleepycat.je.*;
import net.jcip.annotations.ThreadSafe;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.jboss.cache.CacheSPI;
import org.jboss.cache.Fqn;
import org.jboss.cache.Modification;
-import org.jboss.cache.marshall.NodeData;
import org.jboss.cache.config.CacheLoaderConfig.IndividualCacheLoaderConfig;
import org.jboss.cache.loader.AbstractCacheLoader;
+import org.jboss.cache.marshall.NodeData;
import org.jboss.cache.util.reflect.ReflectionUtil;
import java.io.File;
@@ -66,7 +56,7 @@
* <p>The configuration string format is:</p>
* <pre>environmentDirectoryName[#databaseName]</pre>
* <p>where databaseName, if omitted, defaults to the ClusterName property
- * of the CacheImpl.</p>
+ * of the Cache.</p>
* <p/>
* <p>A je.properties file may optionally be placed in the JE environment
* directory and used to customize the default JE configuration.</p>
@@ -156,7 +146,6 @@
}
-
/**
* Opens the JE environment and the database specified by the configuration
* string. The environment and databases are created if necessary.
@@ -182,6 +171,20 @@
config.setLocation(configStr);
}
+ // JBCACHE-1448 db name parsing fix courtesy of Ciro Cavani
+ /* Parse config string. */
+ int offset = configStr.indexOf('#');
+ String cacheDbName;
+ if (offset >= 0 && offset < configStr.length() - 1)
+ {
+ cacheDbName = configStr.substring(offset + 1);
+ configStr = configStr.substring(0, offset);
+ }
+ else
+ {
+ cacheDbName = cache.getClusterName();
+ }
+
// test location
File location = new File(configStr);
if (!location.exists())
@@ -195,19 +198,6 @@
throw new IOException("Cache loader location [" + location + "] is not a directory!");
}
- /* Parse config string. */
- File homeDir;
- int offset = configStr.indexOf('#');
- if (offset >= 0 && offset < configStr.length() - 1)
- {
- homeDir = new File(configStr.substring(0, offset));
- cacheDbName = configStr.substring(offset + 1);
- }
- else
- {
- homeDir = new File(configStr);
- cacheDbName = cache.getClusterName();
- }
catalogDbName = cacheDbName + "_class_catalog";
/*
@@ -224,8 +214,8 @@
envConfig.setAllowCreate(true);
envConfig.setTransactional(true);
envConfig.setLockTimeout(1000 * cache.getConfiguration().getLockAcquisitionTimeout()); // these are in nanos
- if (log.isTraceEnabled()) log.trace("Creating JE environment with home dir " + homeDir);
- env = new Environment(homeDir, envConfig);
+ if (log.isTraceEnabled()) log.trace("Creating JE environment with home dir " + location);
+ env = new Environment(location, envConfig);
if (log.isDebugEnabled()) log.debug("Created JE environment " + env + " for cache loader " + this);
/* Open cache and catalog databases. */
openDatabases();
@@ -585,8 +575,9 @@
throws Exception
{
// JBCACHE-769 -- make a defensive copy
- if (values != null && !(values instanceof HashMap)) {
- values = new HashMap(values);
+ if (values != null && !(values instanceof HashMap))
+ {
+ values = new HashMap(values);
}
/* To update-or-insert, try putNoOverwrite first, then a RMW cycle. */
@@ -911,11 +902,12 @@
{
throw new UnsupportedOperationException(
"prepare() not allowed with a non-transactional cache loader");
- } else if (onePhase)
+ }
+ else if (onePhase)
{
- for (Modification modification: modifications)
+ for (Modification modification : modifications)
{
-
+
}
}
Transaction txn = performTransaction(modifications);
Modified: core/trunk/src/main/java/org/jboss/cache/loader/jdbm/JdbmCacheLoader.java
===================================================================
--- core/trunk/src/main/java/org/jboss/cache/loader/jdbm/JdbmCacheLoader.java 2008-11-26 20:16:12 UTC (rev 7199)
+++ core/trunk/src/main/java/org/jboss/cache/loader/jdbm/JdbmCacheLoader.java 2008-11-26 20:27:59 UTC (rev 7200)
@@ -56,7 +56,7 @@
* <p>The configuration string format is:</p>
* <pre>environmentDirectoryName[#databaseName]</pre>
* <p>where databaseName, if omitted, defaults to the ClusterName property
- * of the CacheImpl.</p>
+ * of the Cache.</p>
* <p/>
* Data is sorted out like:
* <pre>
@@ -123,6 +123,20 @@
config.setLocation(locationStr);
}
+ // JBCACHE-1448 db name parsing fix courtesy of Ciro Cavani
+ /* Parse config string. */
+ int offset = locationStr.indexOf('#');
+ String cacheDbName;
+ if (offset >= 0 && offset < locationStr.length() - 1)
+ {
+ cacheDbName = locationStr.substring(offset + 1);
+ locationStr = locationStr.substring(0, offset);
+ }
+ else
+ {
+ cacheDbName = cache.getClusterName();
+ }
+
// test location
File location = new File(locationStr);
if (!location.exists())
@@ -136,24 +150,9 @@
throw new IOException("Cache loader location [" + location + "] is not a directory!");
}
- /* Parse config string. */
- File homeDir;
- int offset = locationStr.indexOf('#');
- String cacheDbName;
- if (offset >= 0 && offset < locationStr.length() - 1)
- {
- homeDir = new File(locationStr.substring(0, offset));
- cacheDbName = locationStr.substring(offset + 1);
- }
- else
- {
- homeDir = new File(locationStr);
- cacheDbName = cache.getClusterName();
- }
-
try
{
- openDatabase(new File(homeDir, cacheDbName));
+ openDatabase(new File(location, cacheDbName));
}
catch (Exception e)
{
@@ -584,7 +583,7 @@
erase0(m.getFqn(), false);
break;
case REMOVE_KEY_VALUE:
- eraseKey0(m.getFqn(), m.getKey());
+ eraseKey0(m.getFqn(), m.getKey());
break;
case REMOVE_NODE:
erase0(m.getFqn());
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7199 - in core/trunk/src: main/java/org/jboss/cache/interceptors and 1 other directories.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-26 15:16:12 -0500 (Wed, 26 Nov 2008)
New Revision: 7199
Modified:
core/trunk/src/main/java/org/jboss/cache/InvocationContext.java
core/trunk/src/main/java/org/jboss/cache/interceptors/ActivationInterceptor.java
core/trunk/src/main/java/org/jboss/cache/interceptors/LegacyActivationInterceptor.java
core/trunk/src/test/java/org/jboss/cache/passivation/PassivationTestsBase.java
Log:
Optimize activations by minimizing calls to cacheloader.exists()
Modified: core/trunk/src/main/java/org/jboss/cache/InvocationContext.java
===================================================================
--- core/trunk/src/main/java/org/jboss/cache/InvocationContext.java 2008-11-25 12:26:47 UTC (rev 7198)
+++ core/trunk/src/main/java/org/jboss/cache/InvocationContext.java 2008-11-26 20:16:12 UTC (rev 7199)
@@ -69,6 +69,9 @@
@Deprecated
private VisitableCommand command;
+ /**
+ * Set of Fqns loaded by the cache loader interceptor. Only recorded if needed, such as by the ActivationInterceptor
+ */
private Set<Fqn> fqnsLoaded;
/**
@@ -575,12 +578,20 @@
copy.transactionContext = transactionContext;
}
+ /**
+ * Adds an Fqn to the set of Fqns loaded by the cache loader interceptor. Instantiates the set lazily if needed.
+ *
+ * @param fqn fqn to add
+ */
public void addFqnLoaded(Fqn fqn)
{
if (fqnsLoaded == null) fqnsLoaded = new HashSet<Fqn>();
fqnsLoaded.add(fqn);
}
+ /**
+ * @return Set of Fqns loaded by the cache loader interceptor. Only recorded if needed, such as by the ActivationInterceptor
+ */
public Set<Fqn> getFqnsLoaded()
{
return fqnsLoaded;
Modified: core/trunk/src/main/java/org/jboss/cache/interceptors/ActivationInterceptor.java
===================================================================
--- core/trunk/src/main/java/org/jboss/cache/interceptors/ActivationInterceptor.java 2008-11-25 12:26:47 UTC (rev 7198)
+++ core/trunk/src/main/java/org/jboss/cache/interceptors/ActivationInterceptor.java 2008-11-26 20:16:12 UTC (rev 7199)
@@ -24,14 +24,10 @@
import org.jboss.cache.Fqn;
import org.jboss.cache.InternalNode;
import org.jboss.cache.InvocationContext;
-import org.jboss.cache.Modification;
-import org.jboss.cache.commands.AbstractVisitor;
import org.jboss.cache.commands.read.GetChildrenNamesCommand;
import org.jboss.cache.commands.read.GetKeyValueCommand;
import org.jboss.cache.commands.read.GetKeysCommand;
import org.jboss.cache.commands.read.GetNodeCommand;
-import org.jboss.cache.commands.tx.OptimisticPrepareCommand;
-import org.jboss.cache.commands.tx.PrepareCommand;
import org.jboss.cache.commands.write.ClearDataCommand;
import org.jboss.cache.commands.write.MoveCommand;
import org.jboss.cache.commands.write.PutDataMapCommand;
@@ -40,17 +36,12 @@
import org.jboss.cache.commands.write.RemoveKeyCommand;
import org.jboss.cache.commands.write.RemoveNodeCommand;
import org.jboss.cache.factories.annotations.Inject;
-import org.jboss.cache.factories.annotations.Start;
import org.jboss.cache.jmx.annotations.ManagedAttribute;
import org.jboss.cache.jmx.annotations.ManagedOperation;
-import org.jboss.cache.transaction.GlobalTransaction;
-import org.jboss.cache.transaction.TransactionContext;
+import org.jboss.cache.mvcc.ReadCommittedNode;
-import javax.transaction.SystemException;
import javax.transaction.TransactionManager;
-import java.util.ArrayList;
import java.util.HashMap;
-import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
@@ -68,7 +59,6 @@
protected TransactionManager txMgr = null;
private long activations = 0;
- ActivationModificationsBuilder builder;
/**
* List<Transaction> that we have registered for
@@ -88,12 +78,6 @@
this.txMgr = txMgr;
}
- @Start
- public void createModificationsBuilder()
- {
- builder = new ActivationModificationsBuilder();
- }
-
@Override
public Object visitClearDataCommand(InvocationContext ctx, ClearDataCommand command) throws Throwable
{
@@ -210,7 +194,7 @@
if (fqn != null && wasLoadedIntoMemory(ctx, fqn))
{
InternalNode n;
- if (((n = dataContainer.peekInternalNode(fqn, true)) != null) && n.isDataLoaded() && loader.exists(fqn))
+ if (((n = findNode(ctx, fqn)) != null) && n.isDataLoaded() && loader.exists(fqn))
{
// node not null and attributes have been loaded?
if (n.hasChildren())
@@ -231,6 +215,19 @@
}
}
+ private InternalNode findNode(InvocationContext ctx, Fqn fqn)
+ {
+ ReadCommittedNode n = (ReadCommittedNode) ctx.lookUpNode(fqn);
+ if (n == null || n.isNullNode())
+ {
+ return dataContainer.peekInternalNode(fqn, true);
+ }
+ else
+ {
+ return n.getDelegationTarget();
+ }
+ }
+
private boolean childrenLoaded(InternalNode<?, ?> node)
{
if (!node.isChildrenLoaded())
@@ -260,33 +257,6 @@
}
- @Override
- public Object visitOptimisticPrepareCommand(InvocationContext ctx, OptimisticPrepareCommand command) throws Throwable
- {
- Object retval = invokeNextInterceptor(ctx, command);
- if (inTransaction())
- {
- prepareCacheLoader(ctx);
- }
- return retval;
- }
-
- private boolean inTransaction() throws SystemException
- {
- return txMgr != null && txMgr.getTransaction() != null;
- }
-
- @Override
- public Object visitPrepareCommand(InvocationContext ctx, PrepareCommand command) throws Throwable
- {
- Object retval = invokeNextInterceptor(ctx, command);
- if (inTransaction())
- {
- prepareCacheLoader(ctx);
- }
- return retval;
- }
-
private void remove(Fqn fqn) throws Exception
{
loader.remove(fqn);
@@ -311,110 +281,6 @@
}
}
- private void prepareCacheLoader(InvocationContext ctx) throws Throwable
- {
- GlobalTransaction gtx = ctx.getGlobalTransaction();
- TransactionContext tCtx = ctx.getTransactionContext();
- if (tCtx == null)
- {
- throw new Exception("tCtx for transaction " + gtx + " not found in transaction table");
- }
- List<Modification> cacheLoaderModifications = new ArrayList<Modification>();
-
- builder.visitCollection(ctx, tCtx.getModifications());
- if (cacheLoaderModifications.size() > 0)
- {
- loader.prepare(gtx, cacheLoaderModifications, false);
- }
- }
-
- public class ActivationModificationsBuilder extends AbstractVisitor
- {
-
- private List<Modification> cacheLoaderModifications = new ArrayList<Modification>();
-
- private int txActs = 0;
-
- @Override
- public Object visitRemoveNodeCommand(InvocationContext ctx, RemoveNodeCommand removeNodeCommand) throws Throwable
- {
- Modification mod = new Modification(Modification.ModificationType.REMOVE_NODE, removeNodeCommand.getFqn());
- cacheLoaderModifications.add(mod);
- return null;
- }
-
- @Override
- public Object visitPutDataMapCommand(InvocationContext ctx, PutDataMapCommand command) throws Throwable
- {
- Fqn fqn = command.getFqn();
- handlePutCommand(ctx, fqn);
- return null;
- }
-
- @Override
- public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable
- {
- Fqn fqn = command.getFqn();
- handlePutCommand(ctx, fqn);
- return null;
- }
-
- // On the way out, remove the node from the cache loader.
- // Only remove the node if it exists in memory, its attributes have
- // been initialized, its children have been loaded
- // AND it was found in the cache loader (nodeLoaded = true).
- // Then notify the listeners that the node has been activated.
- private void handlePutCommand(InvocationContext ctx, Fqn fqn)
- throws Exception
- {
- if (fqn != null && dataContainer.exists(fqn) && loader.exists(fqn))
- {
- InternalNode n = dataContainer.peekInternalNode(fqn, true);// don't load
- // node not null and attributes have been loaded?
- if (n != null && n.isDataLoaded())
- {
- // has children?
- boolean result = childrenLoaded(n);
- if (n.hasChildren() && result)
- {
- // children have been loaded, remove the node
- addRemoveMod(ctx, cacheLoaderModifications, fqn, n.getData());
- txActs++;
- }
- // doesn't have children, check the cache loader
- else if (loaderNoChildren(fqn))
- {
- addRemoveMod(ctx, cacheLoaderModifications, fqn, n.getData());
- txActs++;
- }
- }
- }
- }
-
- private boolean loaderNoChildren(Fqn fqn) throws Exception
- {
- return loader.getChildrenNames(fqn) != null;
- }
-
- private void addRemoveMod(InvocationContext ctx, List<Modification> l, Fqn fqn, Map data)
- {
- Modification mod = new Modification(Modification.ModificationType.REMOVE_NODE, fqn);
- l.add(mod);
- notifier.notifyNodeActivated(fqn, false, data, ctx);
- }
-
- public List<Modification> getCacheLoaderModifications()
- {
- return cacheLoaderModifications;
- }
-
- public int getTxActs()
- {
- return txActs;
- }
-
- }
-
@ManagedAttribute(description = "number of cache node activations")
public long getActivations()
{
Modified: core/trunk/src/main/java/org/jboss/cache/interceptors/LegacyActivationInterceptor.java
===================================================================
--- core/trunk/src/main/java/org/jboss/cache/interceptors/LegacyActivationInterceptor.java 2008-11-25 12:26:47 UTC (rev 7198)
+++ core/trunk/src/main/java/org/jboss/cache/interceptors/LegacyActivationInterceptor.java 2008-11-26 20:16:12 UTC (rev 7199)
@@ -23,15 +23,11 @@
import org.jboss.cache.Fqn;
import org.jboss.cache.InvocationContext;
-import org.jboss.cache.Modification;
import org.jboss.cache.NodeSPI;
-import org.jboss.cache.commands.AbstractVisitor;
import org.jboss.cache.commands.read.GetChildrenNamesCommand;
import org.jboss.cache.commands.read.GetKeyValueCommand;
import org.jboss.cache.commands.read.GetKeysCommand;
import org.jboss.cache.commands.read.GetNodeCommand;
-import org.jboss.cache.commands.tx.OptimisticPrepareCommand;
-import org.jboss.cache.commands.tx.PrepareCommand;
import org.jboss.cache.commands.write.ClearDataCommand;
import org.jboss.cache.commands.write.MoveCommand;
import org.jboss.cache.commands.write.PutDataMapCommand;
@@ -40,16 +36,10 @@
import org.jboss.cache.commands.write.RemoveKeyCommand;
import org.jboss.cache.commands.write.RemoveNodeCommand;
import org.jboss.cache.factories.annotations.Inject;
-import org.jboss.cache.factories.annotations.Start;
import org.jboss.cache.jmx.annotations.ManagedOperation;
-import org.jboss.cache.transaction.GlobalTransaction;
-import org.jboss.cache.transaction.TransactionContext;
-import javax.transaction.SystemException;
import javax.transaction.TransactionManager;
-import java.util.ArrayList;
import java.util.HashMap;
-import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
@@ -69,7 +59,6 @@
protected TransactionManager txMgr = null;
private long activations = 0;
- ActivationModificationsBuilder builder;
/**
* List<Transaction> that we have registered for
@@ -89,12 +78,6 @@
this.txMgr = txMgr;
}
- @Start
- public void createModificationsBuilder()
- {
- builder = new ActivationModificationsBuilder();
- }
-
@Override
public Object visitClearDataCommand(InvocationContext ctx, ClearDataCommand command) throws Throwable
{
@@ -262,33 +245,6 @@
}
- @Override
- public Object visitOptimisticPrepareCommand(InvocationContext ctx, OptimisticPrepareCommand command) throws Throwable
- {
- Object retval = invokeNextInterceptor(ctx, command);
- if (inTransaction())
- {
- prepareCacheLoader(ctx);
- }
- return retval;
- }
-
- private boolean inTransaction() throws SystemException
- {
- return txMgr != null && txMgr.getTransaction() != null;
- }
-
- @Override
- public Object visitPrepareCommand(InvocationContext ctx, PrepareCommand command) throws Throwable
- {
- Object retval = invokeNextInterceptor(ctx, command);
- if (inTransaction())
- {
- prepareCacheLoader(ctx);
- }
- return retval;
- }
-
private void remove(Fqn fqn) throws Exception
{
loader.remove(fqn);
@@ -318,110 +274,6 @@
return activations;
}
- private void prepareCacheLoader(InvocationContext ctx) throws Throwable
- {
- GlobalTransaction gtx = ctx.getGlobalTransaction();
- TransactionContext tCtx = ctx.getTransactionContext();
- if (tCtx == null)
- {
- throw new Exception("tCtx for transaction " + gtx + " not found in transaction table");
- }
- List<Modification> cacheLoaderModifications = new ArrayList<Modification>();
-
- builder.visitCollection(ctx, tCtx.getModifications());
- if (cacheLoaderModifications.size() > 0)
- {
- loader.prepare(gtx, cacheLoaderModifications, false);
- }
- }
-
- public class ActivationModificationsBuilder extends AbstractVisitor
- {
-
- private List<Modification> cacheLoaderModifications = new ArrayList<Modification>();
-
- private int txActs = 0;
-
- @Override
- public Object visitRemoveNodeCommand(InvocationContext ctx, RemoveNodeCommand removeNodeCommand) throws Throwable
- {
- Modification mod = new Modification(Modification.ModificationType.REMOVE_NODE, removeNodeCommand.getFqn());
- cacheLoaderModifications.add(mod);
- return null;
- }
-
- @Override
- public Object visitPutDataMapCommand(InvocationContext ctx, PutDataMapCommand command) throws Throwable
- {
- Fqn fqn = command.getFqn();
- handlePutCommand(ctx, fqn);
- return null;
- }
-
- @Override
- public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable
- {
- Fqn fqn = command.getFqn();
- handlePutCommand(ctx, fqn);
- return null;
- }
-
- // On the way out, remove the node from the cache loader.
- // Only remove the node if it exists in memory, its attributes have
- // been initialized, its children have been loaded
- // AND it was found in the cache loader (nodeLoaded = true).
- // Then notify the listeners that the node has been activated.
- private void handlePutCommand(InvocationContext ctx, Fqn fqn)
- throws Exception
- {
- if (fqn != null && dataContainer.peek(fqn, false, false) != null && loader.exists(fqn))
- {
- NodeSPI n = dataContainer.peek(fqn, true, false);// don't load
- // node not null and attributes have been loaded?
- if (n != null && n.isDataLoaded())
- {
- // has children?
- boolean result = childrenLoaded(n);
- if (!n.getChildrenDirect().isEmpty() && result)
- {
- // children have been loaded, remove the node
- addRemoveMod(ctx, cacheLoaderModifications, fqn, n.getDataDirect());
- txActs++;
- }
- // doesn't have children, check the cache loader
- else if (loaderNoChildren(fqn))
- {
- addRemoveMod(ctx, cacheLoaderModifications, fqn, n.getDataDirect());
- txActs++;
- }
- }
- }
- }
-
- private boolean loaderNoChildren(Fqn fqn) throws Exception
- {
- return loader.getChildrenNames(fqn) != null;
- }
-
- private void addRemoveMod(InvocationContext ctx, List<Modification> l, Fqn fqn, Map data)
- {
- Modification mod = new Modification(Modification.ModificationType.REMOVE_NODE, fqn);
- l.add(mod);
- notifier.notifyNodeActivated(fqn, false, data, ctx);
- }
-
- public List<Modification> getCacheLoaderModifications()
- {
- return cacheLoaderModifications;
- }
-
- public int getTxActs()
- {
- return txActs;
- }
-
- }
-
@ManagedOperation
public void resetStatistics()
{
Modified: core/trunk/src/test/java/org/jboss/cache/passivation/PassivationTestsBase.java
===================================================================
--- core/trunk/src/test/java/org/jboss/cache/passivation/PassivationTestsBase.java 2008-11-25 12:26:47 UTC (rev 7198)
+++ core/trunk/src/test/java/org/jboss/cache/passivation/PassivationTestsBase.java 2008-11-26 20:16:12 UTC (rev 7199)
@@ -8,6 +8,7 @@
import org.jboss.cache.Modification;
import org.jboss.cache.Node;
import org.jboss.cache.NodeSPI;
+import org.jboss.cache.UnitTestCacheFactory;
import org.jboss.cache.loader.AbstractCacheLoaderTestBase;
import org.jboss.cache.loader.CacheLoader;
import org.jboss.cache.loader.SamplePojo;
@@ -30,7 +31,6 @@
import java.util.List;
import java.util.Map;
import java.util.Set;
-import org.jboss.cache.UnitTestCacheFactory;
/**
* Base tests for passivation using any of the cache loaders
@@ -54,17 +54,17 @@
{
CacheSPI<Object, Object> cache = (CacheSPI<Object, Object>) new UnitTestCacheFactory<Object, Object>().createCache(false);
cache.getConfiguration().setCacheMode("local");
-
+
cacheTL.set(cache);
-
+
configureCache();
cache.getConfiguration().setTransactionManagerLookupClass("org.jboss.cache.transaction.DummyTransactionManagerLookup");
cache.getConfiguration().setIsolationLevel(IsolationLevel.SERIALIZABLE);
cache.create();
cache.start();
- CacheLoader loader = cache.getCacheLoaderManager().getCacheLoader();
-
- loaderTL.set(loader);
+ CacheLoader loader = cache.getCacheLoaderManager().getCacheLoader();
+
+ loaderTL.set(loader);
}
abstract protected void configureCache() throws Exception;
@@ -75,7 +75,7 @@
{
CacheSPI<Object, Object> cache = cacheTL.get();
CacheLoader loader = loaderTL.get();
-
+
log.info("**** TEARING DOWN ****");
if (loader != null) loader.remove(Fqn.ROOT);
TestingUtil.killCaches(cache);
@@ -264,7 +264,7 @@
public void testCacheLoading2() throws Exception
{
- CacheSPI<Object, Object> cache = cacheTL.get();
+ CacheSPI<Object, Object> cache = cacheTL.get();
Set<Object> keys = null;
cache.put("/a/b/c", "key", "val");
@@ -276,7 +276,7 @@
public void testExists() throws Exception
{
- CacheSPI<Object, Object> cache = cacheTL.get();
+ CacheSPI<Object, Object> cache = cacheTL.get();
cache.put("/eins/zwei/drei", "key1", "val1");
assert (exists("/eins/zwei/drei"));
@@ -805,8 +805,8 @@
assertTrue(children.contains("3"));
mgr.commit();
}
-
-
+
+
public void testPutDataMapAfterPassivation() throws Exception
{
CacheSPI<Object, Object> cache = cacheTL.get();
@@ -814,24 +814,24 @@
Fqn f = Fqn.fromString("/a");
assert !cache.exists(f);
- assert !loader.exists(f);
-
+ assert !loader.exists(f);
+
Map<Object, Object> input = new HashMap();
input.put("one", "one");
input.put("two", "two");
cache.put(f, input);
-
+
cache.evict(f);
-
+
input = new HashMap();
- input.put("one", "oneA");
+ input.put("one", "oneA");
cache.put(f, input);
-
+
Map data = cache.getRoot().getChild(f).getData();
assertEquals("incorrect # of entries", 2, data.size());
assertEquals("Has key 'one", "oneA", data.get("one"));
assertEquals("Has key 'two", "two", data.get("two"));
-
+
}
@@ -864,7 +864,41 @@
cache.removeNode(Fqn.ROOT);
}
+ public void testTxReadCommit() throws Exception
+ {
+ CacheSPI<Object, Object> cache = cacheTL.get();
+ CacheLoader loader = loaderTL.get();
+ DummyTransactionManager mgr = DummyTransactionManager.getInstance();
+ mgr.begin();
+
+ cache.put("/one/two/three", "key1", "val1");
+ cache.put("/one/two/three/four", "key2", "val2");
+
+ mgr.commit();
+
+ assertNotNull(cache.getNode("/one/two/three").getKeys());
+ assertEquals("val1", cache.get(Fqn.fromString("/one/two/three"), "key1"));
+ mgr.begin();
+
+ cache.evict(Fqn.fromString("/one/two/three"));
+ cache.evict(Fqn.fromString("/one/two/three/four"));
+
+ mgr.commit();
+ assertTrue(loader.exists(Fqn.fromString("/one/two/three")));
+ assertTrue(loader.exists(Fqn.fromString("/one/two/three/four")));
+
+ // now do a READ in a TX
+ mgr.begin();
+ assert cache.get("/one/two/three", "key1").equals("val1");
+ assert cache.get("/one/two/three/four", "key2").equals("val2");
+ mgr.commit();
+
+ // these should NOT exist in the CL anymore!
+ assert !loader.exists(Fqn.fromString("/one/two/three/four"));
+ }
+
+
public void testTxPutRollback() throws Exception
{
CacheSPI<Object, Object> cache = cacheTL.get();
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7198 - in core/tags/3.0.1.CR2: src/main/java/org/jboss/cache and 1 other directory.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-25 07:26:47 -0500 (Tue, 25 Nov 2008)
New Revision: 7198
Modified:
core/tags/3.0.1.CR2/pom.xml
core/tags/3.0.1.CR2/src/main/java/org/jboss/cache/Version.java
Log:
JBoss Cache Release Script: Updating 3.0.1.CR2
Modified: core/tags/3.0.1.CR2/pom.xml
===================================================================
--- core/tags/3.0.1.CR2/pom.xml 2008-11-25 12:26:09 UTC (rev 7197)
+++ core/tags/3.0.1.CR2/pom.xml 2008-11-25 12:26:47 UTC (rev 7198)
@@ -4,7 +4,7 @@
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<properties>
- <jbosscache-core-version>3.0.0-SNAPSHOT</jbosscache-core-version>
+ <jbosscache-core-version>3.0.1.CR2</jbosscache-core-version>
<!-- By default only run tests in the "unit" group -->
<defaultTestGroup>unit</defaultTestGroup>
<!-- By default only generate Javadocs when we install the module. -->
@@ -443,7 +443,7 @@
<activeByDefault>false</activeByDefault>
</activation>
<properties>
- <jbosscache-core-version>3.0.1-SNAPSHOT-JBossAS</jbosscache-core-version>
+ <jbosscache-core-version>3.0.1.CR2-JBossAS</jbosscache-core-version>
</properties>
<dependencies>
<dependency>
Modified: core/tags/3.0.1.CR2/src/main/java/org/jboss/cache/Version.java
===================================================================
--- core/tags/3.0.1.CR2/src/main/java/org/jboss/cache/Version.java 2008-11-25 12:26:09 UTC (rev 7197)
+++ core/tags/3.0.1.CR2/src/main/java/org/jboss/cache/Version.java 2008-11-25 12:26:47 UTC (rev 7198)
@@ -32,10 +32,10 @@
@Immutable
public class Version
{
- public static final String version = "3.0.1-SNAPSHOT";
+ public static final String version = "3.0.1.CR2";
public static final String codename = "Naga";
//public static final String cvs = "$Id$";
- static final byte[] version_id = {'0', '3', '0', '0', 'S'};
+ static final byte[] version_id = {'0','3','0','1','C','R','2'};
private static final int MAJOR_SHIFT = 11;
private static final int MINOR_SHIFT = 6;
15 years, 5 months
- 1
- 0
JBoss Cache SVN: r7197 - core/tags.
by jbosscache-commits＠lists.jboss.org
Author: manik.surtani(a)jboss.com
Date: 2008-11-25 07:26:09 -0500 (Tue, 25 Nov 2008)
New Revision: 7197
Added:
core/tags/3.0.1.CR2/
Log:
JBoss Cache Release Script: Tagging 3.0.1.CR2
Copied: core/tags/3.0.1.CR2 (from rev 7196, core/trunk)
15 years, 5 months
- 1
- 0