[jboss-cvs] JBossCache/docs/faq/en ...
Manik Surtani
manik at jboss.org
Wed May 30 07:48:51 EDT 2007
User: msurtani
Date: 07/05/30 07:48:51
Modified: docs/faq/en master.xml
Log:
JBCACHE-1033
Revision Changes Path
1.52 +1346 -1333JBossCache/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.51
retrieving revision 1.52
diff -u -b -r1.51 -r1.52
--- master.xml 23 Apr 2007 14:15:07 -0000 1.51
+++ master.xml 30 May 2007 11:48:51 -0000 1.52
@@ -237,1337 +237,1350 @@
<qandaentry>
<question>
- <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>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>
+ <para>How can I migrate my JBoss Cache 1.x.x setup to JBoss Cache 2.x.x?</para>
</question>
-
<answer>
- <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>Refer to
+ <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCache200Migration">our wiki page</ulink>
+ on the subject.
</para>
</answer>
</qandaentry>
<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>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>
+ <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
.
- 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>
- <qandaentry>
- <question>
- <para>What are the
- <literal>EvictionPolicyConfig</literal>
- tag
- parameters for
- <literal>org.jboss.cache.eviction.LRUPolicy</literal>
- ?
- </para>
- </question>
+ MBeanServer serve
+ TreeCacheMBean cach
- <answer>
- <para>They are:</para>
+ public init() throws Excepti
- <table>
- <title>Parameters</title>
+ t
- <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>
+ server = MBeanServerLocator.locateJBoss(
+ cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class, "jboss.cache:service=TreeCache
+ server
- <qandaentry>
- <question>
- <para>I have turned on the eviction policy, why do I still get "out
- of memory" (OOM) exception?
- </para>
- </question>
+ catch (Exception e
- <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>
+ // handle excepti
- <para>The eviction queue size is configurable.
- </para>
- </answer>
- </qandaentry>
- </qandaset>
- </chapter>
- <chapter id="cacheloaders">
- <title>Cache Loaders</title>
- <qandaset>
- <qandaentry>
- <question>
- <para>What is a cache loader?</para>
- </question>
+ public void myBusinessMethod
- <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>
+ Object value = cache.get("/my/node", "myKey"
- <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>
+ HashMap stuff = new HashMap(
+ stuff.put("key1", "value1"
+ stuff.put("key2", "value2"
+ stuff.put("key3", "value3"
- <para>JBoss Cache currently ships with several cache loader
- implementations, including:
- </para>
+ cache.put("/my/new/node", stuff
- <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>
+ cache.remove("/my/node"
- <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>
- <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>
+ </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
- <qandaentry>
- <question>
- <para>Can I write my own cache loader ?</para>
- </question>
+ return getUnMarshalledValue(cache.get(fqn, key)
- <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>
- <qandaentry>
- <question>
- <para>Does a cache loader have to use a persistent store ?</para>
- </question>
+ public Object set(Fqn fqn, String key, Object valu
- <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>
+ cache.put(fqn, key, getMarshalledValue(value)
+ return value; // only if successf
- <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>
- <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>
+ private Object getUnMarshalledValue(object valu
- <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>
+ // assuming we use the calling thread context classload
+ return ((MarshalledValue)value).get(
- <answer>
- <para>Yes. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in the
- JBoss Cache users guide.
- </para>
- </answer>
- </qandaentry>
- </qandaset>
- </chapter>
- <chapter id="troubleshooting">
- <title>Troubleshooting</title>
- <qandaset>
+ private Object getMarshalledValue(Object valu
- <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>
+ 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
+>
</book>
More information about the jboss-cvs-commits
mailing list