[jboss-cvs] JBossCache/docs/faq/en ...
Manik Surtani
msurtani at jboss.com
Tue Oct 31 19:55:31 EST 2006
User: msurtani
Date: 06/10/31 19:55:31
Modified: docs/faq/en Tag: Branch_JBossCache_1_4_0 master.xml
Log:
Updated versioning info to reflect 1.4.1
Revision Changes Path
No revision
No revision
1.34.2.5 +1918 -1459JBossCache/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.34.2.4
retrieving revision 1.34.2.5
diff -u -b -r1.34.2.4 -r1.34.2.5
--- master.xml 9 Jul 2006 17:16:37 -0000 1.34.2.4
+++ master.xml 1 Nov 2006 00:55:30 -0000 1.34.2.5
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"../../../../docbook-support/support/docbook-dtd/docbookx.dtd"
->
+ >
<article class="faq" lang="en">
<articleinfo>
<title>Frequently Asked Questions about JBoss Cache</title>
- <releaseinfo>Release 1.4.0 "Jalapeno"</releaseinfo>
+ <releaseinfo>Release 1.4.1 "Jalapeno"</releaseinfo>
<pubdate>July 2006</pubdate>
<author>
@@ -56,15 +56,25 @@
replicated across the whole group. It is transactional because a
user can configure a JTA compliant transaction manager and make the cache
operation transactional. Note that the cache can also be run without
- any replication; this is the local mode.</para>
+ any replication; this is the local mode.
+ </para>
<para>Currently, JBoss Cache consists of two components: a generic cache
- (implemented internally as <literal>org.jboss.cache.TreeCache</literal>) and a POJO cache (implemented
- internally as <literal>org.jboss.cache.aop.PojoCache</literal>).
- <literal>TreeCache</literal> is a tree-structured cache that provides replication and
- transaction context, while <literal>PojoCache</literal> extends the functionality of
- <literal>TreeCache</literal> but behaves as a true object cache providing transparent
- and finer-grained object mapping into internal cache.</para>
+ (implemented internally as
+ <literal>org.jboss.cache.TreeCache</literal>
+ ) and a POJO cache (implemented
+ internally as
+ <literal>org.jboss.cache.aop.PojoCache</literal>
+ ).
+ <literal>TreeCache</literal>
+ is a tree-structured cache that provides replication and
+ transaction context, while
+ <literal>PojoCache</literal>
+ extends the functionality of
+ <literal>TreeCache</literal>
+ but behaves as a true object cache providing transparent
+ and finer-grained object mapping into internal cache.
+ </para>
</answer>
</qandaentry>
@@ -75,7 +85,9 @@
<answer>
<para>JBossCache has been developed by Bela Ban, Ben Wang, Harald
- Gliebe, Manik Surtani and Brian Stansberry. Manik is the lead on JBoss Cache and Ben is the lead on PojoCache.</para>
+ Gliebe, Manik Surtani and Brian Stansberry. Manik is the lead on JBoss Cache and Ben is the lead on
+ PojoCache.
+ </para>
</answer>
</qandaentry>
@@ -85,7 +97,10 @@
</question>
<answer>
- <para>JBoss Cache is licensed under <ulink url="http://www.gnu.org/licenses/lgpl.html">LGPL</ulink>.</para>
+ <para>JBoss Cache is licensed under
+ <ulink url="http://www.gnu.org/licenses/lgpl.html">LGPL</ulink>
+ .
+ </para>
</answer>
</qandaentry>
@@ -95,7 +110,14 @@
</question>
<answer>
- <para>The JBoss Cache <ulink url="http://www.jboss.com/products/jbosscache/downloads">product download page</ulink> has prebuilt binaries as well as source distributions. You can also grab snapshots from the JBoss CVS repository (see <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=CVSRepository">this wiki page</ulink>) - the module name is <emphasis role="bold">JBossCache</emphasis></para>
+ <para>The JBoss Cache
+ <ulink url="http://www.jboss.com/products/jbosscache/downloads">product download page</ulink>
+ has prebuilt binaries as well as source distributions. You can also grab snapshots from the JBoss CVS
+ repository (see
+ <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=CVSRepository">this wiki page</ulink>
+ ) - the module name is
+ <emphasis role="bold">JBossCache</emphasis>
+ </para>
</answer>
</qandaentry>
@@ -105,13 +127,22 @@
</question>
<answer>
- <para>To build, do <literal>sh build.sh
- jar</literal>. This will produce <literal>jboss-cache.jar</literal>
- in the <literal>dist/lib</literal> directory. Or if you want to
- build the standalone package, do <literal>sh build.sh dist</literal>
+ <para>To build, do
+ <literal>sh build.sh
+ jar
+ </literal>
+ . This will produce
+ <literal>jboss-cache.jar</literal>
+ in the
+ <literal>dist/lib</literal>
+ directory. Or if you want to
+ build the standalone package, do
+ <literal>sh build.sh dist</literal>
this will produce
- <literal>dist/jboss-cache-dist.zip</literal> Note that you will need to
- use JDK 5.0 to build the distribution. You can still use the binaries you build with J2SE 1.4.x though.</para>
+ <literal>dist/jboss-cache-dist.zip</literal>
+ Note that you will need to
+ use JDK 5.0 to build the distribution. You can still use the binaries you build with J2SE 1.4.x though.
+ </para>
</answer>
</qandaentry>
@@ -123,21 +154,34 @@
<answer>
<para>JBoss Cache has been tested and supported on J2SE 1.4.x and JDK 5.0.
On jboss-3.2 CVS tree, it also compiles on JDK1.3, but there is no
- official support for this version and using this is not recommended.</para>
+ official support for this version and using this is not recommended.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="7">
- <para>From JBoss Cache 1.3.0 onwards, there is a new directory <code>lib-50</code>,
- what is it?</para>
+ <para>From JBoss Cache 1.3.0 onwards, there is a new directory
+ <code>lib-50</code>
+ ,
+ what is it?
+ </para>
</question>
<answer>
<para>From JBoss Cache 1.3.0 onwards, we support the use of Java 5 annotations, used by PojoCache.
- As a result, there are <code>jboss-aop-jdk50.jar</code> and <code>jboss-cache-jdk50.jar</code> that
- are needed to work with the Java 5 annotations. You will need to replace <code>jboss-aop.jar</code>
- and <code>jboss-cache.jar</code> in the lib directory with the <code>-jdk50</code> versions if you intend
+ As a result, there are
+ <code>jboss-aop-jdk50.jar</code>
+ and
+ <code>jboss-cache-jdk50.jar</code>
+ that
+ are needed to work with the Java 5 annotations. You will need to replace
+ <code>jboss-aop.jar</code>
+ and
+ <code>jboss-cache.jar</code>
+ in the lib directory with the
+ <code>-jdk50</code>
+ versions if you intend
to use PojoCache, Java 5 and annotations.
</para>
</answer>
@@ -150,14 +194,17 @@
<answer>
<para>Since release 1.2, you can check the jar version by running:
- <code>java -jar jboss-cache.jar org.jboss.cache.Version</code>.</para>
+ <code>java -jar jboss-cache.jar org.jboss.cache.Version</code>
+ .
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="9">
<para>Can I run JBoss Cache outside of JBoss Application
- Server?</para>
+ Server?
+ </para>
</question>
<answer>
@@ -171,7 +218,8 @@
<listitem>
<para>Standalone, that can run in any Java EE server such
as BEA WebLogic or IBM Websphere. Of course, it can also run in
- a standalone Java process (i.e., outside Java EE context).</para>
+ a standalone Java process (i.e., outside Java EE context).
+ </para>
</listitem>
</itemizedlist>
</answer>
@@ -183,9 +231,13 @@
</question>
<answer>
- <para>Please report any bugs or problems to <ulink
+ <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>
+ User Forum
+ </ulink>
+ .
+ </para>
</answer>
</qandaentry>
</qandaset>
@@ -200,12 +252,17 @@
<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
+ 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
+ <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>
+ deploy JBoss Cache as well.
+ </para>
</answer>
</qandaentry>
@@ -218,7 +275,9 @@
<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>
+ <literal>jboss.cache</literal>
+ domain.
+ </para>
</answer>
</qandaentry>
@@ -229,14 +288,15 @@
<answer>
<para>Accessing the JBoss Cache MBean is just like accessing any
- JBoss MBean. Here is a code snippet:</para>
+ 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;
-...
+ 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;
@@ -246,7 +306,8 @@
try
{
server = MBeanServerLocator.locateJBoss();
- cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class, "jboss.cache:service=TreeCache", server);
+ cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class, "jboss.cache:service=TreeCache",
+ server);
}
catch (Exception ex)
{
@@ -270,7 +331,7 @@
...
}
-</programlisting>
+ </programlisting>
</answer>
</qandaentry>
@@ -282,7 +343,8 @@
<answer>
<para>Yes. The JBoss Cache source code is also up to date on the
jboss-3.2 CVS branch. However, only TreeCache is supported there
- since JBossAop (which PojoCache relies on) is only available in JBoss AS 4.x onwards.</para>
+ since JBossAop (which PojoCache relies on) is only available in JBoss AS 4.x onwards.
+ </para>
</answer>
</qandaentry>
@@ -296,24 +358,31 @@
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>
+ need multiple xml configuration files.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="16">
<para>Can TreeCache run as a second level cache inside
- Hibernate?</para>
+ Hibernate?
+ </para>
</question>
<answer>
<para>Yes. Since Hibernate 3.0 release, you can configure it to use
JBoss Cache (namely, TreeCache) 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>
+ 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>
<para>Note that since Hibernate 3.0.2 and JBossCache 1.2.2, we have
fixed a critical bug that depending on the usage pattern can cause
- deadlock during query caching.</para>
+ deadlock during query caching.
+ </para>
</answer>
</qandaentry>
@@ -326,7 +395,8 @@
<para>It is not necessary to use PojoCache for second level
cache inside Hibernate because Hibernate
manages fine-grained fields in Java objects. So using PojoCache won't
- provide any advantage.</para>
+ provide any advantage.
+ </para>
</answer>
</qandaentry>
@@ -338,45 +408,77 @@
<answer>
<para>You can configure the JBoss Cache through a configuration xml
file. Or you can set it programmatically through its get/set methods.
- Check with the documentation for both examples.</para>
+ Check with the documentation for both examples.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="19">
<para>In the configuration xml file, there are tags such as
- <literal>class</literal>, <literal> MBean</literal>, etc. What are
- these?</para>
+ <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>
+ <literal>MBean</literal>
+ tag. If you run in standalone mode,
+ JBoss Cache will ignore these elements.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="20">
<para>What is the difference between the different cache
- modes?</para>
+ 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
+ <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.
+ <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>
+ 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
+ <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>
+ mirror or backup and you don't want to wait for confirmation that this mirror has received your messages.
+ </para>
</answer>
</qandaentry>
@@ -386,17 +488,25 @@
</question>
<answer>
- <para>JBoss Cache leverages <ulink url="http://www.jgroups.org">JGroups</ulink> as a replication layer. A user
+ <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
+ 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>
+ 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. This is on our to do
- list.</para>
+ list.
+ </para>
</answer>
</qandaentry>
@@ -407,8 +517,12 @@
<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>
+ 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>
@@ -421,21 +535,28 @@
<answer>
<para>At this stage (JBoss Cache 1.x) 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>
+ the future.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="24">
- <para>Does the cache need to replicate to every other instance in the cluster? Isn't this slow if the cluster is large?</para>
+ <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>As of JBoss Cache 1.4.0, 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>As of JBoss Cache 1.4.0, 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.
+ See the User Guide for more information on Buddy Replication, and how it can be used to achieve very high
+ scalability.
</para>
</answer>
</qandaentry>
@@ -443,28 +564,38 @@
<qandaentry>
<question id="25">
<para>If I have the need for different TreeCache properties (e.g.,
- <literal>CacheMode</literal> and <literal>IsolationLevel</literal>), do I simply need to create multiple
- TreeCache instances with the appropriate configuration?</para>
+ <literal>CacheMode</literal>
+ and
+ <literal>IsolationLevel</literal>
+ ), do I simply need to create multiple
+ TreeCache instances with the appropriate configuration?
+ </para>
</question>
<answer>
<para>Yes. All the above mentioned properties are per cache
instance. Therefore you will need a separate JBoss Cache
- instance.</para>
+ instance.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="26">
- <para>Does the Tree Cache config <literal>ClusterName</literal> have
+ <para>Does the Tree Cache config
+ <literal>ClusterName</literal>
+ have
any relation to the JBoss AS cluster
- <literal>PartitionName</literal>?</para>
+ <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>
+ group names.
+ </para>
</answer>
</qandaentry>
@@ -473,7 +604,8 @@
<para>When using multiple JGroups based components
[cluster-service.xml, treecache (multiple instances)], what is the
correct/valid way to configure those components to make sure my
- multicast addresses don't conflict?</para>
+ multicast addresses don't conflict?
+ </para>
</question>
<answer>
@@ -482,32 +614,37 @@
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>
+ on different channels.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="28">
<para>Does JBoss Cache currently support cache persistence
- storage?</para>
+ storage?
+ </para>
</question>
<answer>
<para>Yes. Starting with release 1.1, JBoss Cache has a CacheLoader
- interface that supports cache persistence. See below.</para>
+ interface that supports cache persistence. See below.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="29">
<para>Does JBoss Cache currently support cache passivation/ overflow
- to a data store?</para>
+ to a data store?
+ </para>
</question>
<answer>
<para>Yes. Starting with release 1.2.4, JBoss Cache uses the
CacheLoader to support cache passivation/ overflow. See
- documentation on how to configure and use this feature.</para>
+ documentation on how to configure and use this feature.
+ </para>
</answer>
</qandaentry>
@@ -529,14 +666,16 @@
<answer>
<para>No, although it is also on our to do list. Our internal
implementation does use a similar 2PC procedure to coordinate a
- transaction among different instances.</para>
+ transaction among different instances.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="32">
<para>Which TransactionManagers are supported by
- JBoss Cache?</para>
+ JBoss Cache?
+ </para>
</question>
<answer>
@@ -544,11 +683,15 @@
compliant such as JBossTM. A user can configure the transaction
manager through the configuration xml setting. JBossCache also has a
built in dummy transaction manager
- (<literal>org.jboss.cache.tm.DummyTransactionManager</literal>) for
+ (
+ <literal>org.jboss.cache.tm.DummyTransactionManager</literal>
+ ) for
testing purposes only. But note that
- <literal>DummyTransactionManager</literal> is not thread safe .i.e.,
+ <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>
+ transaction is allowed at a time.
+ </para>
</answer>
</qandaentry>
@@ -560,27 +703,32 @@
<answer>
<para>You either use the default (JBoss) TransactionManager to run
JBossCache inside JBoss, or you have to implement the
- <literal>TransactionManagerLookup</literal> interface, and return an
+ <literal>TransactionManagerLookup</literal>
+ interface, and return an
instance of your javax.transaction.TransactionManager. The
configuration property
- <literal>TransactionManagerLookupClass</literal> defines the class
+ <literal>TransactionManagerLookupClass</literal>
+ defines the class
to be used by the cache to fetch a reference to a
TransactionManager. It is trivial to implement this class to support
other TransactionManagers. Once this attribute is specified, the
cache will look up the transaction context from this transaction
- manager.</para>
+ manager.
+ </para>
<para>For the client code, here is a snippet to start and commit a
- transaction:</para>
+ transaction:
+ </para>
<programlisting>tx = (UserTransaction)new InitialContext(prop).lookup("UserTransaction");
-tree = new TreeCache();
-config = new PropertyConfigurator();
-config.configure(tree, "META-INF/replSync-service.xml");
-
-tx.begin()
-tree.put(fqn, key, value);
-tx.commit();</programlisting>
+ tree = new TreeCache();
+ config = new PropertyConfigurator();
+ config.configure(tree, "META-INF/replSync-service.xml");
+
+ tx.begin()
+ tree.put(fqn, key, value);
+ tx.commit();
+ </programlisting>
</answer>
</qandaentry>
@@ -592,15 +740,25 @@
<answer>
<para>JBossCache lets you control the cache locking level through
the transaction isolation level. This is configured through the
- attribute <literal>IsolationLevel</literal>. Currently, JBossCache
+ attribute
+ <literal>IsolationLevel</literal>
+ . Currently, JBossCache
employs pessimistic locking internally. And the transaction
isolation level from the pessimist locking corresponds to JDBC
- 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>
+ 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>
@@ -610,7 +768,11 @@
</question>
<answer>
- <para>By default JBoss Cache uses pessimistic locking to lock data nodes, based on the isolation level configured. Since JBoss Cache 1.3.0, we also offer optimistic locking to allow for greater concurrency at the cost of slight processing overhead and performance. See the documentation for a more detailed discussion on concurrency and locking in JBoss Cache.</para>
+ <para>By default JBoss Cache uses pessimistic locking to lock data nodes, based on the isolation level
+ configured. Since JBoss Cache 1.3.0, 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>
@@ -621,7 +783,20 @@
</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>
+ <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>
@@ -629,28 +804,33 @@
<qandaentry>
<question id="37">
<para>How does the write lock apply to an Fqn node, say,
- "/org/jboss/test"?</para>
+ "/org/jboss/test"?
+ </para>
</question>
<answer>
- <para>First of all, JBossCache has a notion of <literal>root</literal>
+ <para>First of all, JBossCache 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>
+ "/org" (no locking "/").
+ </para>
<para>Furthermore, let's say when JBossCache 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>
+ write lock on "/org/jboss/test".
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="38">
<para>Can I use the cache locking level even without a transaction
- context?</para>
+ context?
+ </para>
</question>
<answer>
@@ -659,14 +839,17 @@
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>
+ <literal>auto_commit</literal>
+ on.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="39">
<para>With replication (REPL_SYNC/REPL_ASYNC) or invalidation (INVALIDATION_SYNC/INVALIDATION_ASYNC), how
- often does the cache broadcast messages over the network?</para>
+ often does the cache broadcast messages over the network?
+ </para>
</question>
<answer>
@@ -676,7 +859,8 @@
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>
+ usually is).
+ </para>
</answer>
</qandaentry>
@@ -687,7 +871,8 @@
<answer>
<para>If you do a cache.remove("/root"), it will recursively remove
- all the entries under "/root".</para>
+ all the entries under "/root".
+ </para>
</answer>
</qandaentry>
@@ -697,7 +882,12 @@
</question>
<answer>
- <para>With JBoss Cache 1.3.0, you can if you are running JBoss Cache within JBoss AS or are using JDK 5.0'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>
+ <para>With JBoss Cache 1.3.0, you can if you are running JBoss Cache within JBoss AS or are using JDK 5.0'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>
@@ -707,15 +897,33 @@
</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>
+ <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 id="43">><para>What is jboss-serialization.jar, introduced in JBoss Cache 1.4.x and do I need this?</para></question>
- <answer><para>jboss-serialization.jar is the <ulink url="http://labs.jboss.org/portal/index.html?ctrl:id=page.default.info&project=serialization">JBoss Serialization</ulink> library, which is much more efficient in terms
- of speed and CPU usage as well as the generated byte stream size than standard Java serialization. This very
- significantly improves replication performance of custom objects placed in the cache.</para>
+ <question id="43">>
+ <para>What is jboss-serialization.jar, introduced in JBoss Cache 1.4.x and do I need this?</para>
+ </question>
+ <answer>
+ <para>jboss-serialization.jar is the
+ <ulink url="http://labs.jboss.org/portal/index.html?ctrl:id=page.default.info&project=serialization">
+ JBoss Serialization
+ </ulink>
+ library, which is much more efficient in terms
+ of speed and CPU usage as well as the generated byte stream size than standard Java serialization. This
+ very
+ significantly improves replication performance of custom objects placed in the cache.
+ </para>
<para>
From 1.4.x, JBoss Cache relies on this library and it is needed to run JBoss Cache.
</para>
@@ -728,7 +936,10 @@
</question>
<answer>
- <para>Yes you can, by passing in the <literal>-Dserialization.jboss=false</literal> environment variable to your JVM.</para>
+ <para>Yes you can, by passing in the
+ <literal>-Dserialization.jboss=false</literal>
+ environment variable to your JVM.
+ </para>
</answer>
</qandaentry>
@@ -742,14 +953,16 @@
<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>
+ group.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="46">
<para>Does JBoss Cache handle the concept of application classloading
- inside, say, a J2EE container?</para>
+ inside, say, a J2EE container?
+ </para>
</question>
<answer>
@@ -757,7 +970,8 @@
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>
+ general, this leads to two kinds of problems:
+ </para>
<itemizedlist>
<listitem>
@@ -767,7 +981,8 @@
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>
+ expecting a type defined by the application classloader.
+ </para>
</listitem>
<listitem>
@@ -775,19 +990,24 @@
accessed by thread 2 (with two different classloaders).
JBossCache has no notion of the different classloaders involved.
As a result, you will have a
- <literal>ClassCastException</literal>. This is a standard
+ <literal>ClassCastException</literal>
+ . This is a standard
problem in passing an object from one application space to
another; JBossCache just adds a level of indirection in passing
- the object.</para>
+ the object.
+ </para>
</listitem>
</itemizedlist>
<para>To solve the first kind of issue, in JBoss Cache 1.2.4 we
- introduced the concept of a <literal>TreeCacheMarshaller</literal>.
+ introduced the concept of a
+ <literal>TreeCacheMarshaller</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 TreeCacheMarshaller section of
- the user guide for more details.</para>
+ 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
@@ -797,17 +1017,21 @@
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>
+ 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
+ called
+ <literal>MarshalledValue</literal>
+ that wraps around the
serialized object. Here is a code snippet that illustrates how you
can create a wrapper around JBossCache to handle the classloader
- issue:</para>
+ issue:
+ </para>
<programlisting>import org.jboss.invocation.MarshalledValue;
-public class CacheService {
+ public class CacheService {
private TreeCache cache_;
public object get(Fqn fqn, String key) {
@@ -819,7 +1043,7 @@
return value; // only if successful
}
-...
+ ...
private Object getUnMarshalledValue(object value) {
// assuming we use the calling thread context classloader
@@ -829,16 +1053,17 @@
private Object getMarshalledValue(Object value) {
return new MarshalledValue(value);
}
-}
+ }
-</programlisting>
+ </programlisting>
</answer>
</qandaentry>
<qandaentry>
<question id="47">
<para>Does JBoss Cache currently support pre-event and post-event
- notification?</para>
+ notification?
+ </para>
</question>
<answer>
@@ -846,14 +1071,17 @@
ExtendedTreeCacheListener which takes in consideration pre and post
event notification. See documentation for more details. Note that
TreeCacheListener and ExtendedTreeCacheListener will be merged into
- TreeCacheListener in release 1.3.</para>
+ TreeCacheListener in release 1.3.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="48">
- <para>How do I implement a custom listener to listen to <literal>TreeCache</literal>
- events?</para>
+ <para>How do I implement a custom listener to listen to
+ <literal>TreeCache</literal>
+ events?
+ </para>
</question>
<answer>
@@ -862,7 +1090,8 @@
the node events that you are interested in. Then you add this
listener to the TreeCache instance on startup to listen to the
events as they occur by calling
- TreeCache.addTreeCacheListener(myListener).</para>
+ TreeCache.addTreeCacheListener(myListener).
+ </para>
<programlisting>
public class MyListener extends AbstractTreeCacheListener
@@ -905,7 +1134,8 @@
manage the object relationship behind the scene. During replication
mode, it performs fine-granularity (i.e., on a per-field basis)
update, and thus has the potential to boost cache performance and
- minimize network traffic.</para>
+ minimize network traffic.
+ </para>
<para>From a user perspective, once your POJO is managed by the
cache, all cache operations are transparent. Therefore, all the
@@ -913,7 +1143,8 @@
ease of use. For example, if a POJO has been put in PojoCache (by
calling putObject, for example), then any get/set method will be
intercepted by PojoCache to provide the data from the
- cache.</para>
+ cache.
+ </para>
</answer>
</qandaentry>
@@ -924,42 +1155,50 @@
<answer>
<para>Since release 1.4, we have created a new class called PojoCache (to better reflect the
- cache nature). The old implementation TreeCacheAop has been deprecated.</para>
+ cache nature). The old implementation TreeCacheAop has been deprecated.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="51">
<para>Does PojoCache have all the functional capabilities of
- TreeCache?</para>
+ TreeCache?
+ </para>
</question>
<answer>
<para>Yes. PojoCache extends TreeCache so it has all the same
features TreeCache such as cache mode, transaction isolation level,
- and eviction policy.</para>
+ and eviction policy.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="52">
<para>What is the difference between TreeCache and
- PojoCache?</para>
+ PojoCache?
+ </para>
</question>
<answer>
<para>Think of PojoCache as a TreeCache on steroids. :-)
Seriously, both are cache stores-- one is a generic cache and the other other one POJO Cache.
However, while TreeCache only
- provides pure object reference storage (e.g., <literal>put(FQN fqn,
- Object key, Object value)</literal>), PojoCache goes beyond that
+ provides pure object reference storage (e.g.,
+ <literal>put(FQN fqn,
+ Object key, Object value)
+ </literal>
+ ), PojoCache goes beyond that
and performs fine-grained field level replication object mapping and
relationship management for a user behind the scenes. As a result,
if you have complex object systems that you would like to cache, you
can have PojoCache manage it for you. You simply treat your
object systems as they are residing in-memory, e.g., use your
regular POJO methods without worrying about cache management.
- Furthermore, this is true in replication mode as well.</para>
+ Furthermore, this is true in replication mode as well.
+ </para>
</answer>
</qandaentry>
@@ -969,35 +1208,50 @@
</question>
<answer>
- <para>Starting from release 1.3, depends on the JDK you use, it has slightly different steps. But in general,
- in order to use PojoCache, you will need to:</para>
+ <para>Starting from release 1.3, depends on the JDK you use, it has slightly different steps. But in
+ general,
+ in order to use PojoCache, you will need to:
+ </para>
<itemizedlist>
- <listitem><para>prepare POJO. You can do either via xml declaration or annotation. For annotation, you can
- use either the JDK1.4 style or JDK50 one (of which is part of JVM spec). If you use JDK14, you will also need
- a annotation pre-compiler (annoc) to pre-process it.</para></listitem>
- <listitem><para>instrumentation. You will need to instrument your POJO either at compile-time or load-time.
- If you do it during compile-time, you use so-called aop pre-compiler (aopc) to do bytecode manipulation.
- If you do it via load-time, however, you need either a special system class loader or, in JDK50, you can
- use the javaagent option.</para></listitem>
+ <listitem>
+ <para>prepare POJO. You can do either via xml declaration or annotation. For annotation, you can
+ use either the JDK1.4 style or JDK50 one (of which is part of JVM spec). If you use JDK14, you will
+ also need
+ a annotation pre-compiler (annoc) to pre-process it.
+ </para>
+ </listitem>
+ <listitem>
+ <para>instrumentation. You will need to instrument your POJO either at compile-time or load-time.
+ If you do it during compile-time, you use so-called aop pre-compiler (aopc) to do bytecode
+ manipulation.
+ If you do it via load-time, however, you need either a special system class loader or, in JDK50,
+ you can
+ use the javaagent option.
+ </para>
+ </listitem>
</itemizedlist>
<para>So if you use JDK50, for example, with annotation and load-time instrumentation, then you won't need
- any pre-processing step to use PojoCache. For a full example, please refer to the distro examples directory.
- There are numerous PojoCache examples that uses different options.</para>
+ any pre-processing step to use PojoCache. For a full example, please refer to the distro examples
+ directory.
+ There are numerous PojoCache examples that uses different options.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="54">
<para>Can I run PojoCache in JBoss AS 3.2.x application
- server?</para>
+ server?
+ </para>
</question>
<answer>
<para>Yes and no. Yes, since JBossAop can also be back-ported to
3.2.x (see JBossAop wiki for details). However, it will take some
effort. Therefore, the recommended JBoss version is 4.x to run
- PojoCache.</para>
+ PojoCache.
+ </para>
</answer>
</qandaentry>
@@ -1010,34 +1264,51 @@
<para>Yes. It is almost the same as TreeCache MBean. The only
difference is the object name and the class name. E.g., instead
of
- <programlisting><mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache"></programlisting>
+ <programlisting><mbean code="org.jboss.cache.TreeCache"
+ name="jboss.cache:service=TreeCache"></programlisting>
you will have:
- <programlisting><mbean code="org.jboss.cache.aop.PojoCache" name="jboss.cache:service=PojoCache"></programlisting>
- in the xml configuration file.</para>
+ <programlisting><mbean code="org.jboss.cache.aop.PojoCache"
+ name="jboss.cache:service=PojoCache"></programlisting>
+ in the xml configuration file.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="56">
<para>Can I pre-compile the aop classes such that I don't need to
- use the system classloader and jboss-aop configuration xml?</para>
+ use the system classloader and jboss-aop configuration xml?
+ </para>
</question>
<answer>
<para>Yes. The latest versions of JBossCache have a pre-compiler
- option called <literal>aopc</literal>. You can use this option to
+ option called
+ <literal>aopc</literal>
+ . You can use this option to
pre-compile your "aspectized" POJO. Once the classes have been byte
code generated, they can be treated as regular class files, i.e.,
- you will not need to include any <literal>jboss-aop.xml</literal>
+ you will not need to include any
+ <literal>jboss-aop.xml</literal>
that specifies the advisable POJO and to specify the JBossAop system
- class loader.</para>
+ class loader.
+ </para>
- <para>For an example of how to use <literal>aopc</literal>, please
- see 1) <literal>tools</literal> directory for PojoCacheTasks14.xml
+ <para>For an example of how to use
+ <literal>aopc</literal>
+ , please
+ see 1)
+ <literal>tools</literal>
+ directory for PojoCacheTasks14.xml
and PojoCacheTasks50.xml. Both contain Ant tasks that you can
- import to your regular project for <literal>annoc</literal> and
- <literal>aopc</literal>. In addition, please also check out the
- <literal>examples</literal> directory for concrete examples.</para>
+ import to your regular project for
+ <literal>annoc</literal>
+ and
+ <literal>aopc</literal>
+ . In addition, please also check out the
+ <literal>examples</literal>
+ directory for concrete examples.
+ </para>
</answer>
</qandaentry>
@@ -1049,29 +1320,41 @@
<answer>
<para>In aopc, you specify the src path for a specific directory. To
pre-compile multiple ones, you will need to invoke aopc multiple
- times.</para>
+ times.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="58">
- <para>What's in the <literal>jboss-aop.xml</literal>
- configuration?</para>
+ <para>What's in the
+ <literal>jboss-aop.xml</literal>
+ configuration?
+ </para>
</question>
<answer>
- <para><literal>jboss-aop.xml</literal> is needed for POJO
- instrumentation. In <literal>jboss-aop.xml</literal>, you can
- declare your POJO (e.g., <literal>Person</literal>) to be
+ <para>
+ <literal>jboss-aop.xml</literal>
+ is needed for POJO
+ instrumentation. In
+ <literal>jboss-aop.xml</literal>
+ , you can
+ declare your POJO (e.g.,
+ <literal>Person</literal>
+ ) to be
"prepared", a JBossAop term to denote that the object will be
"aspectized" by the system. After this declaration, JBossAop will
invoke any interceptor that associates with this POJO. PojoCache
will dynamically add an
- <literal>org.jboss.cache.aop.CacheInterceptor</literal> to this POJO
- to perform object mapping and relationship management.</para>
+ <literal>org.jboss.cache.aop.CacheInterceptor</literal>
+ to this POJO
+ to perform object mapping and relationship management.
+ </para>
<para>Note that to add your POJO, you should declare all the fields
- to be "prepared" as in the example.</para>
+ to be "prepared" as in the example.
+ </para>
</answer>
</qandaentry>
@@ -1082,7 +1365,8 @@
<answer>
<para>Yes, starting with JBossCache 1.3, you can use annotation to
- instrument your POJO for both JDK1.4 and 1.5. Check the documentation for details.</para>
+ instrument your POJO for both JDK1.4 and 1.5. Check the documentation for details.
+ </para>
</answer>
</qandaentry>
@@ -1095,23 +1379,37 @@
<para>It really depends on your organization environment, I'd say, since this can be turned into a
hot debate. Having said that, I feel strongly that POJO annotation is well suited for PojoCache. This is
because once you specify the annotation, you'd probably change it rarely since there is no parameters to
- tune, for example.</para>
+ tune, for example.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="61">
- <para>What are the <literal>@org.jboss.cache.aop.annotation.Transient</literal> and
- <literal>@org.jboss.cache.aop.annotation.Serializable</literal> field level annotations?</para>
+ <para>What are the
+ <literal>@org.jboss.cache.aop.annotation.Transient</literal>
+ and
+ <literal>@org.jboss.cache.aop.annotation.Serializable</literal>
+ field level annotations?
+ </para>
</question>
<answer>
<para>Starting in 1.4, we also offer two additional field-level annotations. The first one,
- <literal>@Transient</literal>,
- when applied has the same effect as declaring a field <literal>transient</literal>. PojoCache
- won't put this field under management.</para>
- <para>The second one, <literal>@Serializable</literal> when applied, will cause PojoCache to
- treat the field as a Serializable object even when it is <literal>@PojoCacheable</literal>.</para>
+ <literal>@Transient</literal>
+ ,
+ when applied has the same effect as declaring a field
+ <literal>transient</literal>
+ . PojoCache
+ won't put this field under management.
+ </para>
+ <para>The second one,
+ <literal>@Serializable</literal>
+ when applied, will cause PojoCache to
+ treat the field as a Serializable object even when it is
+ <literal>@PojoCacheable</literal>
+ .
+ </para>
</answer>
</qandaentry>
@@ -1122,36 +1420,44 @@
<answer>
<para>Again it depends. But my preference is to do compile-time instrumentation via aopc. I prefer this
- approach because it is easier to debug (at least at the development stage). In addition, once I generate the
- new class, there is no more steps needed.</para>
+ approach because it is easier to debug (at least at the development stage). In addition, once I generate
+ the
+ new class, there is no more steps needed.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="63">
<para>Is it possible to store the same object multiple times but
- with different Fqn paths? Like /foo/byName and /foo/byId ?</para>
+ with different Fqn paths? Like /foo/byName and /foo/byId ?
+ </para>
</question>
<answer>
<para>Yes, you can use PojoCache to do that. It supports the
notion of object reference. PojoCache manages the unique object
- through association of the dynamic cache interceptor.</para>
+ through association of the dynamic cache interceptor.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="64">
<para>Do I need to declare all my objects "prepared" in
- <literal>jboss-aop.xml</literal>?</para>
+ <literal>jboss-aop.xml</literal>
+ ?
+ </para>
</question>
<answer>
<para>Not necessarily. If there is an object that you don't need the
cache to manage for you, you can leave it out of the declaration.
The cache will treat this object as a "primitive" type. However, the
- object will need to implement <literal>Serializable</literal>
- interface for replication.</para>
+ object will need to implement
+ <literal>Serializable</literal>
+ interface for replication.
+ </para>
</answer>
</qandaentry>
@@ -1163,109 +1469,143 @@
<answer>
<para>No. The update via reflection will not be intercepted in
JBossAop and therefore PojoCache will not be able to perform the
- necessary synchronization.</para>
+ necessary synchronization.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="66">
<para>When I declare my POJO to be "aspectized", what happens to the
- fields with transient, static, and final modifiers?</para>
+ fields with transient, static, and final modifiers?
+ </para>
</question>
<answer>
<para>PojoCache currently will ignore the fields with these
modifiers. That is, it won't put these fields into the cache (and
- thus no replication either).</para>
+ thus no replication either).
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="67">
<para>What are those keys such as
- <literal>JBoss:internal:class</literal> and
- <literal>AOPInstance</literal>?</para>
+ <literal>JBoss:internal:class</literal>
+ and
+ <literal>AOPInstance</literal>
+ ?
+ </para>
</question>
<answer>
<para>They are for internal use only. Users should ignore these keys
- and values in the node hashmap.</para>
+ and values in the node hashmap.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="68">
<para>What about Collection classes? Do I need to declare them
- "prepared"?</para>
+ "prepared"?
+ </para>
</question>
<answer>
<para>No. Since the Collection classes such as
- <literal>ArrayList</literal> are java util classes, aop by default
+ <literal>ArrayList</literal>
+ are java util classes, aop by default
won't instrument these classes. Instead, PojoCache will generate
a dynamic class proxy for the Collection classes (upon the
- <literal>putObject</literal> call is invoked). The proxy will
+ <literal>putObject</literal>
+ call is invoked). The proxy will
delegate the operations to a cache interceptor that implements the
actual Collection classes APIs. That is, the system classes won't be
- invoked when used in PojoCache.</para>
+ invoked when used in PojoCache.
+ </para>
<para>Internally, the cache interceptor implements the APIs by
direct interaction with respect to the underlying cache store. Note
that this can have implications in performance for certain APIs. For
- example, both <literal>ArrayList</literal> and
- <literal>LinkedList</literal> will have the same implementation.
- Plan is currently underway to optimize these APIs.</para>
+ example, both
+ <literal>ArrayList</literal>
+ and
+ <literal>LinkedList</literal>
+ will have the same implementation.
+ Plan is currently underway to optimize these APIs.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="69">
- <para>How do I use <literal>List</literal>, <literal>Set</literal>,
- and <literal>Map</literal> dynamic proxy?</para>
+ <para>How do I use
+ <literal>List</literal>
+ ,
+ <literal>Set</literal>
+ ,
+ and
+ <literal>Map</literal>
+ dynamic proxy?
+ </para>
</question>
<answer>
<para>PojoCache supports classes extending from
- <literal>List</literal>, <literal>Set</literal>, and
- <literal>Map</literal> without users to declare them "aspectized".
+ <literal>List</literal>
+ ,
+ <literal>Set</literal>
+ , and
+ <literal>Map</literal>
+ without users to declare them "aspectized".
It is done via a dynamic proxy. Here is a code snippet to use an
- <literal>ArrayList</literal> proxy class.</para>
+ <literal>ArrayList</literal>
+ proxy class.
+ </para>
<programlisting>ArrayList list = new ArrayList();
-list.add("first");
+ list.add("first");
-cache.putObject("/list/test", list); // Put the list under the aop cache
-list.add("second"); // Won't work since AOP intercepts the dynamic proxy not the original POJO.
+ cache.putObject("/list/test", list); // Put the list under the aop cache
+ list.add("second"); // Won't work since AOP intercepts the dynamic proxy not the original POJO.
-ArrayList myList = (List)cache.getObject("/list/test"); // we are getting a dynamic proxy instead
-myList.add("second"); // it works now
-myList.add("third");
-myList.remove("third");</programlisting>
+ ArrayList myList = (List)cache.getObject("/list/test"); // we are getting a dynamic proxy instead
+ myList.add("second"); // it works now
+ myList.add("third");
+ myList.remove("third");
+ </programlisting>
</answer>
</qandaentry>
<qandaentry>
<question id="70">
<para>What is the proper way of assigning two different keys with
- Collection class object?</para>
+ Collection class object?
+ </para>
</question>
<answer>
- <para>Let's say you want to assign a <literal>List</literal> object
+ <para>Let's say you want to assign a
+ <literal>List</literal>
+ object
under two different names, you will need to use the class proxy to
insert the second time to ensure both are managed by the cache. Here
- is the code snippet.</para>
+ is the code snippet.
+ </para>
<programlisting>ArrayList list = new ArrayList();
-list.add("first");
+ list.add("first");
-cache.putObject("/list", list); // Put the list under the aop cache
+ cache.putObject("/list", list); // Put the list under the aop cache
-ArrayList myList = (List)cache.getObject("/list"); // we are getting a dynamic proxy instead
-myList.add("second"); // it works now
+ ArrayList myList = (List)cache.getObject("/list"); // we are getting a dynamic proxy instead
+ myList.add("second"); // it works now
-cache.putObject("/list_alias", myList); // Note you will need to use the proxy here!!
-myList.remove("second");</programlisting>
+ cache.putObject("/list_alias", myList); // Note you will need to use the proxy here!!
+ myList.remove("second");
+ </programlisting>
</answer>
</qandaentry>
@@ -1274,7 +1614,9 @@
<para>OK, so I know I am supposed to use proxy when manipulating the
Collection classes once they are managed by the cache. But what
happens to Pojos that share the Collection objects, e.g., a
- <literal>List</literal> instance that is shared by 2 Pojos?</para>
+ <literal>List</literal>
+ instance that is shared by 2 Pojos?
+ </para>
</question>
<answer>
@@ -1282,26 +1624,31 @@
handled by the cache automatically. That is, when you ask the Cache
to manage it, the Cache will dynamically swap out the regular
Collection references with the dynamic proxy ones. As a result, it
- is transparent to the users.</para>
+ is transparent to the users.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="72">
<para>What happens when my "aspectized" POJO has field members that
- are of Collection class ?</para>
+ are of Collection class ?
+ </para>
</question>
<answer>
<para>When a user puts a POJO into the cache through the call
- <literal>putObject</literal>, it will recursively map the field
+ <literal>putObject</literal>
+ , it will recursively map the field
members into the cache store as well. When the field member is of a
Collection class (e.g., List, Set, or Map), PojoCache will first
map the collection into cache. Then, it will swap out dynamically
- the field reference with an corresponding proxy reference.</para>
+ the field reference with an corresponding proxy reference.
+ </para>
<para>This is necessary so that an internal update on the field
- member will be intercepted by the cache.</para>
+ member will be intercepted by the cache.
+ </para>
</answer>
</qandaentry>
@@ -1314,7 +1661,8 @@
<answer>
<para>Use of Collection class in PojoCache helps you to track fine-grained changes
in your collection fields automatically. However, current implementation has the follow
- limitation that we plan to address soon.</para>
+ limitation that we plan to address soon.
+ </para>
<para>Currently, we only support a limited implementation of Collection classes. That is,
we support APIs in List, Set, and Map. However, since the APIs do not stipulate
of constraints like NULL key or value, it makes mapping of user instance to our proxy tricky.
@@ -1323,8 +1671,10 @@
to java.util.ArrayList implementation. The Map interface maps to java.util.HashMap
implementation.
</para>
- <para>Another related issue is the expected performance. For example, the current implementation is ordered, so
- that makes insert/delete from the Collection slow. Performance between Set, Map and List collections also vary.
+ <para>Another related issue is the expected performance. For example, the current implementation is ordered,
+ so
+ that makes insert/delete from the Collection slow. Performance between Set, Map and List collections also
+ vary.
Adding items to a Set is slower than a List or Map, since Set does not allow duplicate entries.
</para>
</answer>
@@ -1339,26 +1689,47 @@
<answer>
<para>As mentioned in the reference doc, PojoCache has the following advantages:</para>
<itemizedlist>
- <listitem><para>Fine-grained replication and/or persistency. If you use a distributed PojoCache
+ <listitem>
+ <para>Fine-grained replication and/or persistency. If you use a distributed PojoCache
and once your POJO is put in the cache store, there is no need to use another API to
trigger your changes. Furthermore, the replication are fine-grained field level. Note this
- also applies to persistency.</para></listitem>
- <listitem><para>Fine-grained replication can have potential performance gain if your POJO is big and
- the changes are fine-grained, e.g., only to some selected fields.</para></listitem>
- <listitem><para>POJO can posses object relationship, e.g., multiple referenced. Distributed
- PojoCache will handle this transparently for you.</para></listitem>
+ also applies to persistency.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Fine-grained replication can have potential performance gain if your POJO is big and
+ the changes are fine-grained, e.g., only to some selected fields.
+ </para>
+ </listitem>
+ <listitem>
+ <para>POJO can posses object relationship, e.g., multiple referenced. Distributed
+ PojoCache will handle this transparently for you.
+ </para>
+ </listitem>
</itemizedlist>
<para>And here are some cases that you may not want to use PojoCache:</para>
<itemizedlist>
- <listitem><para>You use only cache. That is you don't need replication or persistency. Then since
- everything is operated on the in-memory POJO reference, there is no need for PojoCache.</para></listitem>
- <listitem><para>You have simple and small POJOs. Your POJO is small in size and also there is no
- object relationship, then PojoCache possess not clear advantage to plain cache.</para></listitem>
- <listitem><para>Your application is bounded by memory usage. Because PojoCache need almost twice as much
+ <listitem>
+ <para>You use only cache. That is you don't need replication or persistency. Then since
+ everything is operated on the in-memory POJO reference, there is no need for PojoCache.
+ </para>
+ </listitem>
+ <listitem>
+ <para>You have simple and small POJOs. Your POJO is small in size and also there is no
+ object relationship, then PojoCache possess not clear advantage to plain cache.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Your application is bounded by memory usage. Because PojoCache need almost twice as much
of memory (the original POJO in-memory space and also the additional cache store for the
- primitive fields), you may not want to use PojoCache.</para></listitem>
- <listitem><para>Your POJO lifetime is short. That is, you need to create and destroy your POJO often.
- Then you need to do "pubObject" and "removeObject" often, it will be slow in performance.</para></listitem>
+ primitive fields), you may not want to use PojoCache.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Your POJO lifetime is short. That is, you need to create and destroy your POJO often.
+ Then you need to do "pubObject" and "removeObject" often, it will be slow in performance.
+ </para>
+ </listitem>
</itemizedlist>
</answer>
</qandaentry>
@@ -1375,35 +1746,47 @@
<answer>
<para>Yes. JBoss Cache currently implements a LRU eviction policy for
both TreeCache
- (<literal>org.jboss.cache.eviction.LRUPolicy</literal>) and
+ (
+ <literal>org.jboss.cache.eviction.LRUPolicy</literal>
+ ) and
PojoCache
- (<literal>org.jboss.cache.aop.eviction.AopLRUPolicy</literal>). Users
+ (
+ <literal>org.jboss.cache.aop.eviction.AopLRUPolicy</literal>
+ ). Users
can also plug in their own eviction policy algorithms. See user
manual for details. Currently there is user-contributed policy
- called <literal>FIFOPolicy</literal> that evicts the node based on
- FIFO principle only.</para>
+ called
+ <literal>FIFOPolicy</literal>
+ that evicts the node based on
+ FIFO principle only.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="76">
<para>Why can't I use
- <literal>org.jboss.cache.eviction.LRUPolicy</literal> for
- PojoCache as well?</para>
+ <literal>org.jboss.cache.eviction.LRUPolicy</literal>
+ for
+ PojoCache as well?
+ </para>
</question>
<answer>
<para>For PojoCache, you will need to use
- <literal>org.jboss.cache.aop.eviction.AopLRUPolicy</literal>) because
+ <literal>org.jboss.cache.aop.eviction.AopLRUPolicy</literal>
+ ) because
AOP has its eviction algorithm, although is LRU but has totally
- different notion of an "object", for example.</para>
+ different notion of an "object", for example.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="77">
<para>Does JBoss Cache's implemented LRU eviction policy operates in
- replication mode?</para>
+ replication mode?
+ </para>
</question>
<answer>
@@ -1413,49 +1796,72 @@
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
+ <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>
+ 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 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>
+ 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>
+ retrieve it from the store later on.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="78">
- <para>Does JBoss Cache support <literal>Region</literal>?</para>
+ <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>
+ <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>FQN</literal>). For example,
- a user can define <literal>/org/jboss</literal> and
- <literal>/org/foocom</literal> as two separate regions. But note
+ e.g., a fully qualified name (
+ <literal>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>
+ everything has to be configured through the xml file.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="79">
- <para>What are the <literal>EvictionPolicyConfig</literal> tag
+ <para>What are the
+ <literal>EvictionPolicyConfig</literal>
+ tag
parameters for
- <literal>org.jboss.cache.eviction.LRUPolicy</literal>?</para>
+ <literal>org.jboss.cache.eviction.LRUPolicy</literal>
+ ?
+ </para>
</question>
<answer>
@@ -1470,7 +1876,8 @@
<entry>wakeUpIntervalInSeconds</entry>
<entry>Interval where the clean up thread wakes to process
- the sitting queue and sweep away the old data.</entry>
+ the sitting queue and sweep away the old data.
+ </entry>
</row>
<row>
@@ -1478,21 +1885,25 @@
<entry>A area where each eviction policy parameters are
specified. Note that it needs a minimum of
- <literal>/_default</literal> region.</entry>
+ <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>
+ 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>
+ queue. 0 denotes no limit.
+ </entry>
</row>
</tbody>
</tgroup>
@@ -1503,23 +1914,28 @@
<qandaentry>
<question id="80">
<para>I have turned on the eviction policy, why do I still get "out
- of memory" (OOM) exception?</para>
+ of memory" (OOM) exception?
+ </para>
</question>
<answer>
<para>OOM can happen when the speed of cache access exceeds the
speed of eviction policy handling timer. Eviction policy handler
- will wake up every <literal>wakeUpIntervalInSeconds</literal>
+ will wake up every
+ <literal>wakeUpIntervalInSeconds</literal>
seconds to process the eviction event queue. And the queue size is
fixed at 20000 now. So when the queue size is full, it will create a
backlog and cause OOM 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>
+ <literal>wakeUpIntervaleInSeconds</literal>
+ so the timer thread
+ processes the queue more frequently.
+ </para>
<para>We will also externalize the queue size so it will be
- configurable in the next release.</para>
+ configurable in the next release.
+ </para>
</answer>
</qandaentry>
</qandaset>
@@ -1537,7 +1953,8 @@
(persistent) data store. The CacheLoader is called by JBossCache 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 CacheLoader is
- called to store those modifications back to the store.</para>
+ called to store those modifications back to the store.
+ </para>
<para>In conjunction with eviction policies, JBossCache with a
CacheLoader allows a user to maintain a bounded cache for a large
@@ -1545,10 +1962,12 @@
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>
+ care of loading and eviction.
+ </para>
<para>JBossCache currently ships with several CacheLoader
- implementations, including:</para>
+ implementations, including:
+ </para>
<para>
<itemizedlist>
@@ -1556,8 +1975,11 @@
<para>FileCacheLoader: this implementation uses the file
system to store and retrieve data. JBossCache nodes are mapped
to directories, subnodes to subdirectories etc. Attributes of
- a node are mapped to a file <literal>data</literal> inside the
- directory.</para>
+ a node are mapped to a file
+ <literal>data</literal>
+ inside the
+ directory.
+ </para>
</listitem>
<listitem>
@@ -1565,21 +1987,28 @@
Sleepycat Java Edition database, a fast and efficient
transactional database. It uses a single file for the entire
store. Note that if you use Sleepycat's CacheLoader 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 Sleepycat</ulink>.</para>
+ JBoss Cache and wish to ship your product, you will have to acquire a
+ <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from Sleepycat</ulink>
+ .
+ </para>
</listitem>
<listitem>
- <para>JDBCCacheLoader: this implementation uses the relational database as the persistent storage.</para>
+ <para>JDBCCacheLoader: this implementation uses the relational database as the persistent storage.
+ </para>
</listitem>
<listitem>
- <para>ClusteredCacheLoader: this implementation queries the rest of the cluster, treating other servers' in-memory state as a data store.</para>
+ <para>ClusteredCacheLoader: this implementation queries the rest of the cluster, treating other
+ servers' in-memory state as a data store.
+ </para>
</listitem>
<listitem>
<para>And more. See the documentation for more details.</para>
</listitem>
- </itemizedlist></para>
+ </itemizedlist>
+ </para>
</answer>
</qandaentry>
@@ -1592,7 +2021,8 @@
<para>As of JBossCache 1.2.4, yes. Set the CacheLoaderAsynchronous
property to true. See the JBossCache documentation for a more
detailed discussion. By default though, all cache loader writes are
- synchronous and will block.</para>
+ synchronous and will block.
+ </para>
</answer>
</qandaentry>
@@ -1603,9 +2033,11 @@
<answer>
<para>Yes. A CacheLoader is a class implementing
- <literal>org.jboss.cache.loader.CacheLoader</literal>. It is
+ <literal>org.jboss.cache.loader.CacheLoader</literal>
+ . It is
configured via the XML file (see JBossCache and Tutorial
- documentation).</para>
+ documentation).
+ </para>
</answer>
</qandaentry>
@@ -1620,7 +2052,8 @@
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>
+ functionality.
+ </para>
</answer>
</qandaentry>
@@ -1632,20 +2065,25 @@
<answer>
<para>Some applications:</para>
- <para><itemizedlist>
+ <para>
+ <itemizedlist>
<listitem>
<para>HTTP sessions can be persisted (besides being replicated
by JBossCache). The CacheLoader can be configured to be
shared, or unshared, meaning that every node in a cluster has
its own local store. It is also possible to attach a
- CacheLoader to just <emphasis>one</emphasis> of the
- nodes.</para>
+ CacheLoader to just
+ <emphasis>one</emphasis>
+ of the
+ nodes.
+ </para>
</listitem>
<listitem>
<para>Simple persistence for POJOs. Use of JBossCache aop and
a local CacheLoader persist POJOs transparently into the store
- provided by the CacheLoader.</para>
+ provided by the CacheLoader.
+ </para>
</listitem>
<listitem>
@@ -1653,7 +2091,8 @@
The service is up as long as at least 1 node is running, but
even if all nodes are taken offline, when the first node is
started again, the data previously saved will still be
- available (e.g. a shopping cart).</para>
+ available (e.g. a shopping cart).
+ </para>
</listitem>
<listitem>
@@ -1661,9 +2100,11 @@
of URLs, users access the proxy, and if the URL is not in the
cache, the CacheLoader fetches it from the web. This could
actually be a replicated and transactional version of
- Squid.</para>
+ Squid.
+ </para>
</listitem>
- </itemizedlist></para>
+ </itemizedlist>
+ </para>
</answer>
</qandaentry>
@@ -1676,7 +2117,8 @@
<para>Through XML: both the fully-qualified classname of the
CacheLoader and its configuration string have to be given.
JBossCache will then instantiate a CacheLoader. See JBossCache
- documentation for details.</para>
+ documentation for details.
+ </para>
</answer>
</qandaentry>
@@ -1688,8 +2130,12 @@
<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 Sleepycat. See details at <ulink
- url="http://www.sleepycat.com/jeforjbosscache">http://www.sleepycat.com/jeforjbosscache</ulink>.</para>
+ a commercial license from Sleepycat. See details at
+ <ulink
+ url="http://www.sleepycat.com/jeforjbosscache">http://www.sleepycat.com/jeforjbosscache
+ </ulink>
+ .
+ </para>
</answer>
</qandaentry>
@@ -1706,35 +2152,48 @@
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>
+ cache loader.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="89">
- <para>Why do cache loaders go into an inconsistent state when I use transactions, pessimistic locking, and I attempt to read a node after removing it from within the same transaction scope?</para>
+ <para>Why do cache loaders go into an inconsistent state when I use transactions, pessimistic locking, and I
+ attempt to read a node after removing it from within the same transaction scope?
+ </para>
</question>
<answer>
- <para>This is a known bug (see <ulink url="http://jira.jboss.com/jira/browse/JBCACHE-477">JBCACHE-477</ulink> and <ulink url="http://jira.jboss.com/jira/browse/JBCACHE-352">JBCACHE-352</ulink>), which have been fixed in JBoss Cache 1.4.0. A very simple workaround if you're using JBoss Cache 1.3.x is to use optimistic locking.</para>
+ <para>This is a known bug (see
+ <ulink url="http://jira.jboss.com/jira/browse/JBCACHE-477">JBCACHE-477</ulink>
+ and
+ <ulink url="http://jira.jboss.com/jira/browse/JBCACHE-352">JBCACHE-352</ulink>
+ ), which have been fixed in JBoss Cache 1.4.0. A very simple workaround if you're using JBoss Cache 1.3.x
+ is to use optimistic locking.
+ </para>
<para>
- One of the consequences of this bug is that, for example, if you use PojoCache with pojos that have private references to a List and you update and remove someelements of that List within a transaction (when using pessimistic locking and a cache loader), you may see IllegalStateExceptions thrown.
+ One of the consequences of this bug is that, for example, if you use PojoCache with pojos that have
+ private references to a List and you update and remove someelements of that List within a transaction
+ (when using pessimistic locking and a cache loader), you may see IllegalStateExceptions thrown.
</para>
</answer>
</qandaentry>
-
</qandaset>
<qandaset defaultlabel="Troubleshooting">
<title>Troubleshooting</title>
<qandaentry>
<question id="90">
- <para>I am having problems getting JBoss Cache to work, where can I get information on troubleshooting?</para>
+ <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>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>
More information about the jboss-cvs-commits
mailing list