[jboss-cvs] JBossCache/docs/faq/en ...
Manik Surtani
manik at jboss.org
Wed Jun 6 13:42:02 EDT 2007
User: msurtani
Date: 07/06/06 13:42:02
Modified: docs/faq/en master.xml
Log:
Rolled back and ee-applied JBCACHE-1033 to fix JBCACHE-1081
Revision Changes Path
1.53 +1342 -1346JBossCache/docs/faq/en/master.xml
(In the diff below, changes in quantity of whitespace are not shown.)
Index: master.xml
===================================================================
RCS file: /cvsroot/jboss/JBossCache/docs/faq/en/master.xml,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -b -r1.52 -r1.53
--- master.xml 30 May 2007 11:48:51 -0000 1.52
+++ master.xml 6 Jun 2007 17:42:02 -0000 1.53
@@ -237,1350 +237,1346 @@
<qandaentry>
<question>
- <para>How can I migrate my JBoss Cache 1.x.x setup to JBoss Cache 2.x.x?</para>
+ <para>Can I run JBoss Cache outside of JBoss Application
+ Server?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ Of course! Even though JBoss Cache comes integrated with JBoss Application Server as an MBean service,
+ it
+ can also be run standalone, in any 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 user 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://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCache200Migration">this wiki page</ulink> for help.</para>
+ </answer>
+ </qandaentry>
+
+ <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/index.html?module=bb&op=viewforum&f=157">JBoss Cache
+ User Forum
+ </ulink>
+ .
+ </para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </chapter>
+
+ <chapter id="TreeCache">
+ <title>JBoss Cache - Core</title>
+
+ <qandaset>
+
+ <qandaentry>
+ <question>
+ <para>How do I deploy JBoss Cache as a MBean service?</para>
+ </question>
+
+ <answer>
+ <para>To deploy JBoss Cache as an MBean inside JBoss, you can copy the
+ configuration xml file over to the
+ <literal>deploy</literal>
+ directory (from
+ <literal>all</literal>
+ configuration whereby the
+ necessary jars are present). Under the standalone package
+ <literal>etc/META-INF</literal>
+ directory , there are example
+ configuration files for different cache modes that can be used to
+ deploy JBoss Cache as well.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>How do I know if my JBoss Cache MBean has been deployed?</para>
+ </question>
+
+ <answer>
+ <para>To verify that your JBoss Cache MBean is deployed correctly,
+ you can first check the log output under the command console. Next
+ you can verify it from JBoss JMX console. Look for
+ <literal>jboss.cache</literal>
+ domain.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>How do I access the JBoss Cache MBean?</para>
+ </question>
+
+ <answer>
+ <para>Accessing the JBoss Cache MBean is just like accessing any
+ JBoss MBean. Here is a code snippet:
+ </para>
+
+ <programlisting>
+ import org.jboss.mx.util.MBeanServerLocator;
+ import org.jboss.mx.util.MBeanProxyExt;
+ import org.jboss.cache.TreeCacheMBean;
+ import javax.management.MBeanServer;
+ ...
+
+ MBeanServer server;
+ TreeCacheMBean cache;
+
+ public init() throws Exception
+ {
+ try
+ {
+ server = MBeanServerLocator.locateJBoss();
+ cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class, "jboss.cache:service=TreeCache",
+ server);
+ }
+ catch (Exception ex)
+ {
+ // handle exception
+ }
+ }
+
+ public void myBusinessMethod()
+ {
+ Object value = cache.get("/my/node", "myKey");
+
+ HashMap stuff = new HashMap();
+ stuff.put("key1", "value1");
+ stuff.put("key2", "value2");
+ stuff.put("key3", "value3");
+
+ cache.put("/my/new/node", stuff);
+
+ cache.remove("/my/node");
+
+ ...
+ }
+
+ </programlisting>
+ </answer>
+ </qandaentry>
+
+ <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>
+
+ <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://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate">
+ http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate
+ </ulink>
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>What about using Pojo Cache as a Hibernate cache?</para>
+ </question>
+
+ <answer>
+ <para>It is not necessary to use PojoCache for second level
+ cache inside Hibernate because Hibernate
+ manages fine-grained fields in Java objects. Using PojoCache won't
+ provide any advantage.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <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>
+
+ <qandaentry>
+ <question>
+ <para>In the configuration xml file, there are tags such as
+ <literal>class</literal>
+ ,
+ <literal>MBean</literal>
+ , etc. What are
+ these?
+ </para>
+ </question>
+
+ <answer>
+ <para>These are tags for deploying JBoss Cache as a JBoss MBean
+ service. For consistency, we have kept them in the
+ standalone package as well, specifically, the
+ <literal>MBean</literal>
+ tag. If you run in standalone mode,
+ JBoss Cache will ignore these elements.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <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>
+
+ <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>
+
+ <answer>
+ <para>JBoss Cache leverages
+ <ulink url="http://www.jgroups.org">JGroups</ulink>
+ as a replication layer. 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
+ user 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>
+
+ <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>
+
+ <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>
+
+ <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 User Guide for more information on Buddy Replication, and how it can be used to achieve very
+ high
+ scalability.
+ </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>
+
+ <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>
+
+ <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 User Guide for details on how to configure the JGroups
+ Multiplexer.
+ </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>
+
+ <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>
+
+ <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>
+
+ <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>
+
+ <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>
+
+ <answer>
+ <para>Yes, it is thread safe.</para>
+ </answer>
+ </qandaentry>
+
+ <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>
+
+ <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 JBossTM or JBossTS. JBoss Cache ships with a
+ dummy transaction manager
+ (
+ <literal>org.jboss.cache.transaction.DummyTransactionManager</literal>
+ ) for
+ testing purposes only. But note that
+ <literal>DummyTransactionManager</literal>
+ is not thread safe .i.e.,
+ it does not support concurrent transactions. Instead, only one
+ transaction is allowed at a time.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <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>
+
+ </answer>
+ </qandaentry>
+
+ <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>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>How does JBoss Cache lock data for concurrent access?</para>
+ </question>
+
+ <answer>
+ <para>By default JBoss Cache uses pessimistic locking 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>
+ </answer>
+ </qandaentry>
+
+
+ <qandaentry>
+ <question>
+ <para>How do I enable Optimistic Locking in JBoss Cache?</para>
+ </question>
+
+ <answer>
+ <para>Use the XMl attribute
+ <code>NodeLockingScheme</code>
+ . Note that
+ <code>IsolationLevel</code>
+ is ignored if
+ <code>NodeLockingScheme</code>
+ is set to
+ <code>OPTIMISTIC</code>
+ . Also note that
+ <code>NodeLockingScheme</code>
+ defaults to
+ <code>PESSIMISTIC</code>
+ if omitted.
+ </para>
+ </answer>
+ </qandaentry>
+
+
+ <qandaentry>
+ <question>
+ <para>How does the write lock apply to an Fqn node, say,
+ "/org/jboss/test"?
+ </para>
+ </question>
+
+ <answer>
+ <para>First of all, JBoss Cache has a notion of
+ <literal>root</literal>
+ that serves as a starting point for every navigational operation.
+ The default is "/" (since the default separator is "/" for the fqn).
+ The locking then is applied to the node under root, for example
+ "/org" (no locking "/").
+ </para>
+
+ <para>Furthermore, let's say when JBoss Cache needs to apply a write
+ lock on node "/org/jboss/test", it will first try to obtain read
+ lock from the parent nodes recursively (in this example, "/org", and
+ "/org/jboss"). Only when it succeeds then it will try to obtain a
+ write lock on "/org/jboss/test".
+ </para>
+ </answer>
+ </qandaentry>
+
+ <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>
+
+ <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 implication if network transport is heavy (it
+ usually is).
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>How can I do a mass removal?</para>
+ </question>
+
+ <answer>
+ <para>If you do a cache.removeNode(Fqn.fromString("/myroot")), 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>
+
+ <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 user guide for more details.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>Can I disable JBoss Cache management attributes?</para>
+ </question>
+
+ <answer>
+ <para>Yes, you can. Set the
+ <literal>UseInterceptorMbeans</literal>
+ configuration attribute to
+ <literal>false</literal>
+ (this defaults to
+ <literal>true</literal>
+ ). See the chapter titled
+ <emphasis role="bold">Management Information</emphasis>
+ in the JBoss Cache user guide for more details.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>What happened to jboss-serialization.jar?</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>
+
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support partitioning?</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>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache handle the concept of application classloading
+ inside, say, a J2EE container?
+ </para>
+ </question>
+
+ <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>
+
+ <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>
+
+ <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 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 user guide for more details.
+ </para>
+
+ <para>To solve the second kind of issue, the only solution (that we
+ know of) is to cache "serialized" byte code and only de-serialize it
+ during every object get (and this will be expensive!). That is,
+ during a put operation, the object instance will be serialized and
+ therefore can be deserialized safely by a "foreign" classloader.
+ However, the performance penalty of this approach is quite severe so
+ in general another local in-vm version will need to be used as a
+ "near-line" cache. Note also that each time the serialized bytes are
+ deserialized, a new instance of the object is created.
+ </para>
+
+ <para>To help with this kind of handling, JBoss has a utility class
+ called
+ <literal>MarshalledValue</literal>
+ that wraps around the
+ serialized object. Here is a code snippet that illustrates how you
+ can create a wrapper around JBoss Cache to handle the classloader
+ issue:
+ </para>
+
+ <programlisting>
+ import org.jboss.invocation.MarshalledValue;
+
+ public class CacheService
+ {
+ private Cache cache;
+
+ public Object get(Fqn fqn, String key)
+ {
+ return getUnMarshalledValue(cache.get(fqn, key));
+ }
+
+ public Object set(Fqn fqn, String key, Object value)
+ {
+ cache.put(fqn, key, getMarshalledValue(value));
+ return value; // only if successful
+ }
+
+ ...
+
+ private Object getUnMarshalledValue(object value)
+ {
+ // assuming we use the calling thread context classloader
+ return ((MarshalledValue)value).get();
+ }
+
+ private Object getMarshalledValue(Object value)
+ {
+ return new MarshalledValue(value);
+ }
+ }
+ </programlisting>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache currently support pre-event and post-event
+ notification?
+ </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.CacheListener</literal>
+ interface for details.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>How do I implement a custom listener to listen to
+ cache events?
+ </para>
</question>
+
<answer>
- <para>Refer to
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCache200Migration">our wiki page</ulink>
- on the subject.
+ <para>
+ Either implement
+ <literal>org.jboss.cache.CacheListener</literal>
+ or extend
+ <literal>org.jboss.cache.AbstractCacheListener</literal>
+ and override for the events you are interested in. You can then register the listener using the
+ <literal>org.jboss.cache.Cache.addCacheListener()</literal>
+ API.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
- <para>Can I run JBoss Cache outside of JBoss Applicati
- Serve
- </par
- </questio
-
- <answe
- <par
- Of course! Even though JBoss Cache comes integrated with JBoss Application Server as an MBean servic
-
- can also be run standalone, in any Java EE server such as BEA WebLogic, IBM Websphere or Tomcat.
- can also run
- a standalone Java process, completely outside of an application server. See the user guide for mo
- detail
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Where can I report bugs or problems?</par
- </questio
-
- <answe
- <para>Please report any bugs or problems
- <uli
- url="http://www.jboss.org/index.html?module=bb&op=viewforum&f=157">JBoss Cac
- User For
- </ulin
-
- </par
- </answe
- </qandaentr
- </qandase
- </chapte
-
- <chapt r id="TreeCache
- <title>JBoss Cache - Core</titl
-
- <qandase
-
- <qandaentr
- <questio
- <para>How do I deploy JBoss Cache as a MBean service?</par
- </questio
-
- <answe
- <para>To deploy JBoss Cache as an MBean inside JBoss, you can copy t
- configuration xml file over to t
- <literal>deploy</litera
- directory (fr
- <literal>all</litera
- configuration whereby t
- necessary jars are present). Under the standalone packa
- <literal>etc/META-INF</litera
- directory , there are examp
- configuration files for different cache modes that can be used
- deploy JBoss Cache as wel
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How do I know if my JBoss Cache MBean has been deployed?</par
- </questio
-
- <answe
- <para>To verify that your JBoss Cache MBean is deployed correctl
- you can first check the log output under the command console. Ne
- you can verify it from JBoss JMX console. Look f
- <literal>jboss.cache</litera
- domai
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How do I access the JBoss Cache MBean?</par
- </questio
-
- <answe
- <para>Accessing the JBoss Cache MBean is just like accessing a
- JBoss MBean. Here is a code snippe
- </par
-
- <programlistin
- import org.jboss.mx.util.MBeanServerLocato
- import org.jboss.mx.util.MBeanProxyEx
- import org.jboss.cache.TreeCacheMBea
- import javax.management.MBeanServe
+ <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>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>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>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>To implement this feature, please follow the instructions indicated in the example located
+ in the CacheMarshaller section of the user's 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>
+
+ </qandaset>
+ </chapter>
+
+ <chapter id="eviction">
+ <title>Eviction Policies</title>
+ <qandaset>
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support eviction policies?</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
+ manual for details.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache's eviction policy operates in
+ replication mode?
+ </para>
+ </question>
+
+ <answer>
+ <para>Yes and no. :-)</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>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>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>
+
+ <qandaentry>
+ <question>
+ <para>Does JBoss Cache support
+ <literal>Region</literal>
+ ?
+ </para>
+ </question>
+
+ <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>
+
+ <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>
- MBeanServer serve
- TreeCacheMBean cach
+ <qandaentry>
+ <question>
+ <para>What are the
+ <literal>EvictionPolicyConfig</literal>
+ tag
+ parameters for
+ <literal>org.jboss.cache.eviction.LRUPolicy</literal>
+ ?
+ </para>
+ </question>
- public init() throws Excepti
+ <answer>
+ <para>They are:</para>
- t
+ <table>
+ <title>Parameters</title>
- server = MBeanServerLocator.locateJBoss(
- cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class, "jboss.cache:service=TreeCache
- server
+ <tgroup cols="2">
+ <tbody>
+ <row>
+ <entry>eventQueueSize</entry>
+
+ <entry>A fine-tuning parameter where you can configure the size of the eviction notification
+ event queue. Defaults to 200,000.
+ </entry>
+ </row>
+
+ <row>
+ <entry>wakeUpIntervalInSeconds</entry>
+
+ <entry>Interval where the clean up thread wakes to process
+ the sitting queue and sweep away the old data.
+ </entry>
+ </row>
+
+ <row>
+ <entry>region</entry>
+
+ <entry>A area where each eviction policy parameters are
+ specified. Note that it needs a minimum of
+ <literal>/_default</literal>
+ region.
+ </entry>
+ </row>
+
+ <row>
+ <entry>maxNodes</entry>
+
+ <entry>Max number of nodes allowed in the eviction queue. 0
+ means no limit.
+ </entry>
+ </row>
+
+ <row>
+ <entry>timeToLiveInSeconds</entry>
+
+ <entry>Age (in seconds) for the node to be evicted in the
+ queue. 0 denotes no limit.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </answer>
+ </qandaentry>
- catch (Exception e
+ <qandaentry>
+ <question>
+ <para>I have turned on the eviction policy, why do I still get "out
+ of memory" (OOM) exception?
+ </para>
+ </question>
- // handle excepti
+ <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>wakeUpIntervalInSeconds</literal>
+ seconds 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>wakeUpIntervaleInSeconds</literal>
+ so the timer thread
+ processes the queue more frequently.
+ </para>
+ <para>The eviction queue size is configurable.
+ </para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </chapter>
+ <chapter id="cacheloaders">
+ <title>Cache Loaders</title>
+ <qandaset>
- public void myBusinessMethod
+ <qandaentry>
+ <question>
+ <para>What is a cache loader?</para>
+ </question>
- Object value = cache.get("/my/node", "myKey"
+ <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>
- HashMap stuff = new HashMap(
- stuff.put("key1", "value1"
- stuff.put("key2", "value2"
- stuff.put("key3", "value3"
+ <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>
- cache.put("/my/new/node", stuff
+ <para>JBoss Cache currently ships with several cache loader
+ implementations, including:
+ </para>
- cache.remove("/my/node"
+ <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.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.JDBCCacheLoader</literal>
+ : this implementation uses the relational database as the persistent
+ storage.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>And more. See the chapter on cache loaders in the User Guide for more details.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>Is the FileCacheLoader recommended for production use?</para>
+ </question>
+
+ <answer>
+ <para>
+ No, it is not. The FileCacheLoader has some severe limitations which restrict it's 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>
+
+ As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly concurrent,
+ transactional or stressful environment, and it's use is restricted to testing.
+ </para>
+ </answer>
+ </qandaentry>
+ <qandaentry>
+ <question>
+ <para>Can writing to cache loaders be asynchronous?</para>
+ </question>
- </programlistin
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I run multiple JBoss Cache instances on the same VM?</par
- </questio
-
- <answe
- <para>Yes. There are some scenarios where you may want to r
- multiple instances of JBoss Cache. For example, you want to r
- multiple local cache instances with each instance having its o
- configuration (e.g., different cache policy). In this case, you wi
- need multiple xml configuration file
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can JBoss Cache run as a second level cache insi
- Hibernat
- </par
- </questio
-
- <answe
- <para>Yes. Since Hibernate 3.0 release, you can configure it to u
- JBoss Cache as a second level cache. For detail
- see Hibernate documentation, and also s
- <uli k url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernate
- http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHiberna
- </ulin
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>What about using Pojo Cache as a Hibernate cache?</par
- </questio
-
- <answe
- <para>It is not necessary to use PojoCache for second lev
- cache inside Hibernate because Hiberna
- manages fine-grained fields in Java objects. Using PojoCache won
- provide any advantag
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How can I configure JBoss Cache?</par
- </questio
-
- <answe
- <para>You can configure the JBoss Cache through a configuration x
- file or programmatically using
- <literal>org.jboss.cache.config.Configuration</litera
- object, passed in to t
- <literal>org.jboss.cache.CacheFactory</litera
- instanc
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>In the configuration xml file, there are tags such
- <literal>class</litera
-
- <literal>MBean</litera
- , etc. What a
- thes
- </par
- </questio
-
- <answe
- <para>These are tags for deploying JBoss Cache as a JBoss MBe
- service. For consistency, we have kept them in t
- standalone package as well, specifically, t
- <literal>MBean</litera
- tag. If you run in standalone mod
- JBoss Cache will ignore these element
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>What is the difference between the different cac
- mode
- </par
- </questio
-
- <answe
- <para>JBossCache has five different cache modes, i.e
- <literal>LOCAL</litera
-
- <literal>REPL_SYNC</litera
-
- <literal>REPL_ASYNC</litera
-
- <literal>INVALIDATION_SYNC</litera
- a
- <literal>INVALIDATION_ASYNC</litera
- . If you want to run JBoss Cache as
- single instance, then you should set the cache mode
- <literal>LOCAL</litera
- so that it won't attempt to replicate anythin
- If you want to have synchronous replication among differe
- JBoss Cache instances, you set it
- <literal>REPL_SYNC</litera
-
- For asynchronous replication, u
- <literal>AYSNC_REPL</litera
- . If you do not wish to replicate cached data but simply inform other caches in a cluster that da
- und
- specific addresses are now stale and should be evicted from memory, u
- <literal>INVALIDATION_SYNC</litera
-
- <literal>INVALIDTAION_ASYNC</litera
- . Synchronous and asynchronous behavior applies to invalidation as well as replicatio
- </par
-
- <para>Note th
- <literal>ASYNC_REPL</litera
- a
- <literal>INVALIDATION_ASYNC</litera
- are non-blocking. Th
- can be useful when you want to have another JBoss Cache serving as
- mirror or backup and you don't want to wait for confirmation that this mirror has received yo
- message
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How does JBoss Cache's replication mechanism work?</par
- </questio
-
- <answe
- <para>JBoss Cache leverag
- <uli k url="http://www.jgroups.org">JGroups</ulin
- as a replication layer. A us
- can configure the cluster of JBoss Cache instances by sharing t
- same cluster name
- <literal>cluster name</litera
- ). There is al
- an option of whether to populate the cache data upon starting a n
- instance in t
- <literal>ClusterConfig</litera
- attribut
- </par
-
- <para>Note that once all instances join the same replication grou
- every replication change is propagated to all participating member
- There is no mechanism for sub-partitioning where some replicati
- can be done within only a subset of members, unless you use the Buddy Replication features. See t
- user guide for more details on thi
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>I run a 2 node cluster. If the network dies, do the caches continue to run?</par
- </questio
-
- <answe
- <para>Yes, both will continue to run, but depending on your replication mode, all transactions
- operations may not complete.
- <literal>REPL_SYNC</litera
- is used, operations will fail while
- <literal>REPL_ASYNC</litera
- is used they will succeed. Even if they succeed though, caches will be out of syn
- </par
- </answe
- </qandaentr
-
-
- <qandaentr
- <questio
- <para>Can I plug in library X instead of JGroups to handle remote calls and group communications?</par
- </questio
-
- <answe
- <para>At this stage the answer is no. We do have an abstraction layer between t
- communication suite and JBoss Cache in the pipelines, and this may appear as a feature at some sta
-
- the futur
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does the cache need to replicate to every other instance in the cluster? Isn't this slow if t
- cluster is larg
- </par
- </questio
-
- <answe
- <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. Th
- allows a cluster to sca
- very easily with no extra impact on memory or network traffic with each node adde
- </par
- <par
- See the User Guide for more information on Buddy Replication, and how it can be used to achieve ve
- hi
- scalabilit
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>If I have the need for different configuration properties (e.g
- <literal>CacheMode</litera
- a
- <literal>IsolationLevel</litera
- ), do I simply need to create multip
- <literal>org.jboss.cache.Cache</litera
- instances with the appropriate configuratio
- </par
- </questio
-
- <answe
- <para>Yes. All the above mentioned properties are per cac
- instance. Therefore you will need separa
- <literal>org.jboss.cache.Cache</litera
- instance
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Isn't this expensive from a networking standpoint, i.e., needing to create sockets for ea
- <literal>org.jboss.cache.Cache</litera
- instanc
- </par
- </questio
-
- <answe
- <par
- Yes, it can be. For such cases it is recommended that you configure your cache using the JGrou
- Multiplexer, which allows several caches to sha
- a single JGroups channel. Please see the User Guide for details on how to configure the JGrou
- Multiplexe
- </par
- </answe
- </qandaentr
-
-
- <qandaentr
- <questio
- <para>Does t
- <literal>ClusterName</litera
- configuration element ha
- any relation to the JBoss AS clust
- <literal>PartitionName</litera
-
- </par
- </questio
-
- <answe
- <para>Yes. They are both JGroups group names. Besides the notion
- a channel in JGroups, it also can partition the channel into differe
- group name
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>When using multiple JGroups based componen
- [cluster-service.xml, cache (multiple instances)], what is t
- correct/valid way to configure those components to make sure
- multicast addresses don't conflic
- </par
- </questio
-
- <answe
- <para>There are two parameters to consider: multicast address (pl
- port) and the group name. At minimum, you will have to r
- components using a different group name. But whether to run them
- the same channel depends upon whether the communication performan
- is critical for you or not. If it is, then it'd be best to run th
- on different channel
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache support cache persisten
- storag
- </par
- </questio
-
- <answe
- <para>Yes. JBoss Cache has a cache load
- interface that supports cache persistence. See below for more FAQs on cache loader
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache support cache passivation/ overfl
- to a data stor
- </par
- </questio
-
- <answe
- <para>Yes. JBoss Cache uses t
- cache loader to support cache passivation/ overflow. S
- documentation on how to configure and use this featur
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Is JBoss Cache thread safe?</par
- </questio
-
- <answe
- <para>Yes, it is thread safe.</par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache support XA (2PC) transactions now?</par
- </questio
-
- <answe
- <para>No, although it is also on our to do list. Our intern
- implementation does use a procedure similar to 2PC to coordinate
- transactions among different instances, but JBoss Cache is not an XA resourc
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Which transaction managers are supported
- JBoss Cach
- </par
- </questio
-
- <answe
- <para>JBoss Cache supports any TransactionManager that
- <uli k url="http://java.sun.com/products/jta/">JTA</ulin
- compliant such as JBossTM or JBossTS. JBoss Cache ships with
- dummy transaction manag
-
- <literal>org.jboss.cache.transaction.DummyTransactionManager</litera
- ) f
- testing purposes only. But note th
- <literal>DummyTransactionManager</litera
- is not thread safe .i.e
- it does not support concurrent transactions. Instead, only o
- transaction is allowed at a tim
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How do I set up the cache to be transactional?</par
- </questio
-
- <answe
- <para>You either use the default transaction manager that ships with JBoss
- or you have to implement t
- <literal>org.jboss.cache.transaction.TransactionManagerLookup</litera
- interface, and return
- instance of yo
- <literal>javax.transaction.TransactionManager</litera
- implementation. T
- configuration proper
- <literal>TransactionManagerLookupClass</litera
- defines the cla
- to be used by the cache to fetch a reference to
- transaction manager. It is trivial to implement this interface to suppo
- other transaction managers. Once this attribute is specified, t
- cache will look up the transaction context from this transacti
- manage
- </par
-
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How do I control the cache locking level?</par
- </questio
-
- <answe
- <para>JBoss Cache lets you control the cache locking level throu
- the transaction isolation level. This is configured through t
- attribu
- <literal>IsolationLevel</litera
- . The transacti
- isolation levels correspond to databa
- isolation levels, namel
- <literal>NONE</litera
-
- <literal>READ_UNCOMMITTED</litera
-
- <literal>READ_COMMITTED</litera
-
- <literal>REPEATABLE_READ</litera
- , a
- <literal>SERIALIZABLE</litera
- . Note that these isolation levels are ignored if optimistic locking is used. For details, plea
- ref
- to t
- user manua
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How does JBoss Cache lock data for concurrent access?</par
- </questio
-
- <answe
- <para>By default JBoss Cache uses pessimistic locking to lock data nodes, based on the isolation lev
- configured. We also offer optimistic locking to allow for greater concurren
-
- the cost of slight processing overhead and performance. See the documentation for a more detail
- discussion on concurrency and locking in JBoss Cach
- </par
- </answe
- </qandaentr
-
-
- <qandaentr
- <questio
- <para>How do I enable Optimistic Locking in JBoss Cache?</par
- </questio
-
- <answe
- <para>Use the XMl attribu
- <code>NodeLockingScheme</cod
- . Note th
- <code>IsolationLevel</cod
- is ignored
- <code>NodeLockingScheme</cod
- is set
- <code>OPTIMISTIC</cod
- . Also note th
- <code>NodeLockingScheme</cod
- defaults
- <code>PESSIMISTIC</cod
- if omitte
- </par
- </answe
- </qandaentr
-
-
- <qandaentr
- <questio
- <para>How does the write lock apply to an Fqn node, sa
- "/org/jboss/test
- </par
- </questio
-
- <answe
- <para>First of all, JBoss Cache has a notion
- <literal>root</litera
- that serves as a starting point for every navigational operatio
- The default is "/" (since the default separator is "/" for the fqn
- The locking then is applied to the node under root, for examp
- "/org" (no locking "/"
- </par
-
- <para>Furthermore, let's say when JBoss Cache needs to apply a wri
- lock on node "/org/jboss/test", it will first try to obtain re
- lock from the parent nodes recursively (in this example, "/org", a
- "/org/jboss"). Only when it succeeds then it will try to obtain
- write lock on "/org/jboss/test
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I use the cache locking level even without a transacti
- contex
- </par
- </questio
-
- <answe
- <para>Yes. JBoss Cache controls the individual node locking behavi
- through the isolation level semantics. This means even if you don
- use a transaction, you can specify the lock level via isolati
- level. You can think of the node locking behavior outside of
- transaction as if it is under transaction wi
- <literal>auto_commit</litera
- o
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>With replication (REPL_SYNC/REPL_ASYNC) or invalidation (INVALIDATION_SYNC/INVALIDATION_ASYNC), h
- often does the cache broadcast messages over the networ
- </par
- </questio
-
- <answe
- <para>If the updates are under transaction, then the broadcas
- happen only when the transaction is about to commit (actual
- during the prepare stage internally). That is, it will be a bat
- update. However, if the operations are not under transacti
- context, then each update will trigger replication. Note that th
- has performance implication if network transport is heavy (
- usually is
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How can I do a mass removal?</par
- </questio
-
- <answe
- <para>If you do a cache.removeNode(Fqn.fromString("/myroot")), it will recursively remo
- all the entries under "/myroot
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I monitor and manage the JBoss Cache?</par
- </questio
-
- <answe
- <para>Yes, using a JMX console such as the one shipped with JBoss AS or Java 5
- <literal>jconsole</litera
- utility. See the chapter titl
- <emphas s role="bold">Management Information</emphasi
- in the JBoss Cache user guide for more detail
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I disable JBoss Cache management attributes?</par
- </questio
-
- <answe
- <para>Yes, you can. Set t
- <literal>UseInterceptorMbeans</litera
- configuration attribute
- <literal>false</litera
- (this defaults
- <literal>true</litera
- ). See the chapter titl
- <emphas s role="bold">Management Information</emphasi
- in the JBoss Cache user guide for more detail
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>What happened to jboss-serialization.jar?</par
- </questio
-
- <answe
- <par
- As of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of t
- benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0
- baselined on Java 5, there was no need to provide these benefits separatel
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache support partitioning?</par
- </questio
-
- <answe
- <para>Not right now. JBoss Cache does not support partitioning that
- user can configure to have different set of data residing
- different cache instances while still participating as a replicati
- grou
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache handle the concept of application classloadi
- inside, say, a J2EE containe
- </par
- </questio
-
- <answe
- <para>Application-specific classloading is used widely inside a Java
- container. For example, a web application may require a n
- classloader to scope a specific version of the user librar
- However, by default JBoss Cache is agnostic to the classloader.
- general, this leads to two kinds of problem
- </par
-
- <itemizedlis
- <listite
- <para>Object instance is stored in cache1 and replicated
- cache2. As a result, the instance in cache2 is created by t
- system classloader. The replication may fail if the syst
- classloader on cache2 does not have access to the requir
- class. Even if replication doesn't fail, a user thread in cach
- may not be able to access the object if the user thread
- expecting a type defined by the application classloade
- </par
- </listite
-
- <listite
- <para>Object instance is created by thread 1 and will
- accessed by thread 2 (with two different classloaders
- JBoss Cache has no notion of the different classloaders involve
- As a result, you will have
- <literal>ClassCastException</litera
- . This is a standa
- problem in passing an object from one application space
- another; JBoss Cache just adds a level of indirection in passi
- the objec
- </par
- </listite
- </itemizedlis
-
- <para>To solve the first kind of issue JBoss Cache uses
- <literal>CacheMarshaller</litera
-
- Basically, this allows application code to register a classload
- with a portion of the cache tree for use in handling objec
- replicated to that portion. See t
- <literal>CacheMarshaller</litera
- section
- the user guide for more detail
- </par
-
- <para>To solve the second kind of issue, the only solution (that
- know of) is to cache "serialized" byte code and only de-serialize
- during every object get (and this will be expensive!). That i
- during a put operation, the object instance will be serialized a
- therefore can be deserialized safely by a "foreign" classloade
- However, the performance penalty of this approach is quite severe
- in general another local in-vm version will need to be used as
- "near-line" cache. Note also that each time the serialized bytes a
- deserialized, a new instance of the object is create
- </par
-
- <para>To help with this kind of handling, JBoss has a utility cla
- call
- <literal>MarshalledValue</litera
- that wraps around t
- serialized object. Here is a code snippet that illustrates how y
- can create a wrapper around JBoss Cache to handle the classload
- issu
- </par
-
- <programlistin
- import org.jboss.invocation.MarshalledValu
-
- public class CacheServi
-
- private Cache cach
-
- public Object get(Fqn fqn, String ke
+ <answer>
+ <para>Yes. Set the
+ <literal>async</literal>
+ attrobute to true. See the JBoss Cache User Guide for a more
+ detailed discussion. By default though, all cache loader writes are
+ synchronous and will block.
+ </para>
+ </answer>
+ </qandaentry>
- return getUnMarshalledValue(cache.get(fqn, key)
+ <qandaentry>
+ <question>
+ <para>Can I write my own cache loader ?</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 User Guide).
+ </para>
+ </answer>
+ </qandaentry>
- public Object set(Fqn fqn, String key, Object valu
+ <qandaentry>
+ <question>
+ <para>Does a cache loader have to use a persistent store ?</para>
+ </question>
- cache.put(fqn, key, getMarshalledValue(value)
- return value; // only if successf
+ <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>Do I have to pay to use Oracle's Berkeley DB CacheLoader?</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>
+
+ <qandaentry>
+ <question>
+ <para>Can I use more than one cache loader?</para>
+ </question>
- private Object getUnMarshalledValue(object valu
+ <answer>
+ <para>Yes. Within the CacheLoaderConfiguration XML
+ element (see user 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>
- // assuming we use the calling thread context classload
- return ((MarshalledValue)value).get(
+ <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. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in the
+ JBoss Cache users guide.
+ </para>
+ </answer>
+ </qandaentry>
- private Object getMarshalledValue(Object valu
+ </qandaset>
+ </chapter>
+ <chapter id="troubleshooting">
+ <title>Troubleshooting</title>
+ <qandaset>
- return new MarshalledValue(value
-
-
- </programlistin
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache currently support pre-event and post-eve
- notificatio
- </par
- </questio
-
- <answe
- <para>Yes. A boolean is passed in to each notification callback identifying whether the callback
- befo
- or after the event. See t
- <literal>org.jboss.cache.CacheListener</litera
- interface for detail
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>How do I implement a custom listener to listen
- cache event
- </par
- </questio
-
- <answe
- <par
- Either impleme
- <literal>org.jboss.cache.CacheListener</litera
- or exte
- <literal>org.jboss.cache.AbstractCacheListener</litera
- and override for the events you are interested in. You can then register the listener using t
- <literal>org.jboss.cache.Cache.addCacheListener()</litera
- AP
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I u
- <literal>UseRegionBasedMarshalling</litera
- attribute in JBoss Cache in order to g
- around ClassCastExceptions happening when accessing data in the cache that has just been redeploye
- </par
- </questio
-
- <answe
- <para>Yes, you can. Originally, cache Marshalling was designed as
- workaround for those replicated caches that upon state transfer did not have access to t
- classloaders defining the objects in the cach
- </par
-
- <para>On each deployment, JBoss creates a new classloader per the top level deployment artifact, f
- example an EAR. You also have to bear in mind that a class in an application server is defined n
- only by the class name but also its classloader. So, assuming that the cache is not deployed as pa
- of your deployment, you could deploy an application and put instances of classes belonging to th
- deployment inside the cache. If you did a redeployment and try to do a get operation of the da
- previously put, this would result on a ClassCastException. This is because even though the class nam
- are the same, the class definitions are not. The current classloader is different to the one wh
- the classes were originally pu
- </par
-
- <para>By enabling marshalling, you can control the lifecycle of the data in the cache and if
- undeployment, you deactivate the region and unregister the classloader that you'd have registered
- deployment, you'd evict the data in the cache locally. That means that in the next deployment, t
- data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to g
- around this problem is only recommended when you have some kind of persistence backing where the da
- survives, for example using CacheLoaders, or when JBoss Cache is used as a second level cache in
- persistence framewor
- </par
-
- <para>To implement this feature, please follow the instructions indicated in the example locat
- in the CacheMarshaller section of the user's guide. It's worth noting that instead of
- <literal>ServletContextListener</litera
- , you could add this code into
- <literal>MBean</litera
- that contained lifecycle methods, such
- <literal>start()</litera
- a
- <literal>stop()</litera
-
- The key would be for this MBean to depend on the target cache, so that it can operate as long as t
- cache is up and runnin
- </par
- </answe
- </qandaentr
-
- </qandase
- </chapte
-
- <chapt r id="eviction
- <title>Eviction Policies</titl
- <qandase
- <qandaentr
- <questio
- <para>Does JBoss Cache support eviction policies?</par
- </questio
-
- <answe
- <para>Yes. JBoss Cache currently supports multiple eviction policies such as LRU, MRU, and FIF
- Users can also plug in their own eviction policy algorithms. See us
- manual for detail
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache's eviction policy operates
- replication mod
- </par
- </questio
-
- <answe
- <para>Yes and no. :-)</par
-
- <para>The eviction policy only operates in local mode. That is, nodes a
- only evicted locally. This may cause the cache contents not to
- synchronized temporarily. But when a user tries to obtain the cach
- contents of an evicted node and finds out that is null (e.g
- <literal>get</litera
- returns null), it should get it from t
- other data source and re-populate the data in the cache. During th
- moment, the node content will be propagated and the cache conte
- will be in syn
- </par
-
- <para>However, you still can run eviction policies with cache mo
- set to eith
- <literal>REPL_SYNC</litera
-
- <literal>REPL_ASYNC</litera
- . Depending on your use case, you c
- set multiple cache instances to have their own eviction poli
- (which are applied locally) or just have selected instances wi
- eviction policies activate
- </par
-
- <para>Also note that, with cache loader option, a locally evict
- node can also be persisted to the backend store and a user c
- retrieve it from the store later o
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does JBoss Cache suppo
- <literal>Region</litera
-
- </par
- </questio
-
- <answe
- <para>Yes. JBoss Cache has the notion of region where a user c
- configure the eviction policy parameters (e.g
- <literal>maxNodes</litera
-
- <literal>timeToIdleSeconds</litera
-
- </par
-
- <para>A region in JBoss Cache denotes a portion of tree hierarch
- e.g., a fully qualified name
- <literal>org.jboss.cache.Fqn</litera
- ). For exampl
- a user can defi
- <literal>/org/jboss</litera
- a
- <literal>/org/foocom</litera
- as two separate regions. But no
- that you can configure the region programmatically now, i.e
- everything has to be configured through the xml fil
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>What are t
- <literal>EvictionPolicyConfig</litera
- t
- parameters f
- <literal>org.jboss.cache.eviction.LRUPolicy</litera
-
- </par
- </questio
-
- <answe
- <para>They are:</par
-
- <tabl
- <title>Parameters</titl
-
- <tgro p cols="2
- <tbod
- <ro
- <entry>eventQueueSize</entr
-
- <entry>A fine-tuning parameter where you can configure the size of the eviction notificati
- event queue. Defaults to 200,00
- </entr
- </ro
-
- <ro
- <entry>wakeUpIntervalInSeconds</entr
-
- <entry>Interval where the clean up thread wakes to proce
- the sitting queue and sweep away the old dat
- </entr
- </ro
-
- <ro
- <entry>region</entr
-
- <entry>A area where each eviction policy parameters a
- specified. Note that it needs a minimum
- <literal>/_default</litera
- regio
- </entr
- </ro
-
- <ro
- <entry>maxNodes</entr
-
- <entry>Max number of nodes allowed in the eviction queue.
- means no limi
- </entr
- </ro
-
- <ro
- <entry>timeToLiveInSeconds</entr
-
- <entry>Age (in seconds) for the node to be evicted in t
- queue. 0 denotes no limi
- </entr
- </ro
- </tbod
- </tgrou
- </tabl
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>I have turned on the eviction policy, why do I still get "o
- of memory" (OOM) exceptio
- </par
- </questio
-
- <answe
- <para>OOM can happen when the speed of cache access exceeds t
- speed of eviction policy handling timer. Eviction policy handl
- will wake up eve
- <literal>wakeUpIntervalInSeconds</litera
- seconds to process the eviction event queue. So when the queue size is full, it will create
- backlog and cause out-of-memory exceptions to happen unless the eviction timer catch
- up. To address this problem, in addition to increase the VM he
- size, you can also reduce t
- <literal>wakeUpIntervaleInSeconds</litera
- so the timer thre
- processes the queue more frequentl
- </par
-
- <para>The eviction queue size is configurabl
- </par
- </answe
- </qandaentr
- </qandase
- </chapte
- <chapt r id="cacheloaders
- <title>Cache Loaders</titl
- <qandase
-
-
- <qandaentr
- <questio
- <para>What is a cache loader?</par
- </questio
-
- <answe
- <para>A cache loader is the connection of JBoss Cache to
- (persistent) data store. The cache loader is called by JBoss Cache
- fetch data from a store when that data is not in the cache, and wh
- modifications are made to data in the cache the Cache Loader
- called to store those modifications back to the stor
- </par
-
- <para>In conjunction with eviction policies, JBoss Cache with
- cache loader allows a user to maintain a bounded cache for a lar
- backend datastore. Frequently used data is fetched from t
- datastore into the cache, and the least used data is evicted,
- order to provide fast access to frequently accessed data. This
- all configured through XML, and the programmer doesn't have to ta
- care of loading and evictio
- </par
-
- <para>JBoss Cache currently ships with several cache load
- implementations, includin
- </par
-
- <par
- <itemizedlis
- <listite
- <par
- <literal>org.jboss.cache.loader.FileCacheLoader</litera
- : this implementation uses the fi
- system to store and retrieve data. JBoss Cache nodes are mapp
- to directories, subnodes to subdirectories etc. Attributes
- a node are mapped to a data fi
- inside t
- director
- </par
- </listite
-
- <listite
- <par
- <literal>org.jboss.cache.loader.BdbjeCacheLoader</litera
- : this implementation is based on t
- Oracle's Berkeley DB Java Edition database, a fast and efficie
- transactional database. It uses a single file for the enti
- store. Note that if you use the Berkeley DB cache loader wi
- JBoss Cache and wish to ship your product, you will have to acquire
- <uli k url="http://www.sleepycat.com/jeforjbosscache">commercial license from Orac
- </ulin
-
- </par
- </listite
-
- <listite
- <par
- <literal>org.jboss.cache.loader.JDBCCacheLoader</litera
- : this implementation uses the relational database as the persiste
- storag
- </par
- </listite
-
- <listite
- <para>And more. See the chapter on cache loaders in the User Guide for more details.</par
- </listite
- </itemizedlis
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Is the FileCacheLoader recommended for production use?</par
- </questio
-
- <answe
- <par
- No, it is not. The FileCacheLoader has some severe limitations which restrict it's use in a producti
- environment, or if used in such an environment, it should be used with due care and sufficie
- understanding of these limitation
- <itemizedlis
- <listitem>Due to the way the FileCacheLoader represents a tree structure on disk (directories a
- files) traversal is inefficient for deep tree
- </listite
- <listitem>Usage on shared filesystems like NFS, Windows shares, etc. should be avoided as these
- not implement proper file locking and can cause data corruptio
- </listite
- <listitem>Usage with an isolation level of NONE can cause corrupt writes as multiple threa
- attempt to write to the same fil
- </listite
- <listitem>File systems are inherently not transactional, so when attempting to use your cache in
- transactional context, failures when writing to the file (which happens during the commit phas
- cannot be recovere
- </listite
- </itemizedlis
-
- As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly concurren
- transactional or stressful environment, and it's use is restricted to testin
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can writing to cache loaders be asynchronous?</par
- </questio
-
- <answe
- <para>Yes. Set t
- <literal>async</litera
- attrobute to true. See the JBoss Cache User Guide for a mo
- detailed discussion. By default though, all cache loader writes a
- synchronous and will bloc
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I write my own cache loader ?</par
- </questio
-
- <answe
- <para>Yes. A cache loader is a class implementi
- <literal>org.jboss.cache.loader.CacheLoader</litera
- or extendi
- <literal>org.jboss.cache.loader.AbstractCacheLoader</litera
- . It
- configured via the XML file (see JBoss Cache User Guide
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Does a cache loader have to use a persistent store ?</par
- </questio
-
- <answe
- <para>No, a cache loader could for example fetch (and possibly stor
- its data from a webdav-capable webserver. Another example is
- caching proxy server, which fetches contents from the web. Note th
- an implementation of CacheLoader may not implement the 'stor
- functionality in this case, but just the 'loa
- functionalit
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Do I have to pay to use Oracle's Berkeley DB CacheLoader?</par
- </questio
-
- <answe
- <para>Not if you use it only for personal use. As soon as y
- distribute your product with BdbjeCacheLoader, you have to purcha
- a commercial license from Oracle. See details
- <uli
- url="http://www.sleepycat.com/jeforjbosscache">http://www.sleepycat.com/jeforjbosscac
- </ulin
-
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I use more than one cache loader?</par
- </questio
-
- <answe
- <para>Yes. Within the CacheLoaderConfiguration X
- element (see user guide chapter on cache loaders) you c
- describe several cache loaders. The impact is that the cache wi
- look at all of the cache loaders in the order they've be
- configured, until it finds a valid, non-null element of data. Wh
- performing writes, all cache loaders are written to (except if t
- ignoreModifications element has been set to true for a specif
- cache loade
- </par
- </answe
- </qandaentr
-
- <qandaentr
- <questio
- <para>Can I migrate a JDBCacheLoader or FileCacheLoader based cache store containing data formatted wi
- JBoss Cache 1.x.x to JBoss Cache 2.0 forma
- </par
- </questio
-
- <answe
- <para>Yes. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in t
- JBoss Cache users guid
- </par
- </answe
- </qandaentr
-
- </qandase
- </chapte
- <chapt r id="troubleshooting
- <title>Troubleshooting</titl
- <qandase
-
- <qandaentr
- <questio
- <para>I am having problems getting JBoss Cache to work, where can I get information on troubleshootin
- </par
- </questio
- <answe
- <para>Troubleshooting section can be found in the followi
- <uli k url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheTroubleshooting">wiki link</ulin
-
- </par
- </answe
- </qandaentr
- </qandase
- </chapte
->
+ <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://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheTroubleshooting">wiki link</ulink>
+ .
+ </para>
+ </answer>
+ </qandaentry>
+ </qandaset>
+ </chapter>
</book>
More information about the jboss-cvs-commits
mailing list