[jbosscache-commits] JBoss Cache SVN: r6935 - core/trunk/src/main/docbook/faq/en.

jbosscache-commits at lists.jboss.org jbosscache-commits at lists.jboss.org
Tue Oct 14 11:17:56 EDT 2008


Author: manik.surtani at jboss.com
Date: 2008-10-14 11:17:56 -0400 (Tue, 14 Oct 2008)
New Revision: 6935

Modified:
   core/trunk/src/main/docbook/faq/en/master.xml
Log:
Updated FAQs to 3.x

Modified: core/trunk/src/main/docbook/faq/en/master.xml
===================================================================
--- core/trunk/src/main/docbook/faq/en/master.xml	2008-10-14 13:52:34 UTC (rev 6934)
+++ core/trunk/src/main/docbook/faq/en/master.xml	2008-10-14 15:17:56 UTC (rev 6935)
@@ -43,14 +43,14 @@
          <para>This is a compilation of the most frequently asked
             questions about JBoss Cache. Please report any bugs,
             inconsistencies, or omissions you find in this FAQ on the
-            <ulink url="http://jboss.org/index.html?module=bb&amp;op=main&amp;c=29">JBoss Cache User Form
+            <ulink url="http://jboss.org/index.html?module=bb&amp;op=main&amp;c=29">JBoss Cache User Forum
             </ulink>
             .
          </para>
          <para>
-            This FAQ is divided into specific sections, all pertaining to the core JBoss Cache library. PojoCache has a
+            This FAQ is divided into specific sections, all pertaining to the core JBoss Cache library. POJO Cache has a
             separate FAQ
-            document pertaining to PojoCache specifics.
+            document pertaining to POJO Cache specifics.
          </para>
       </abstract>
 
@@ -84,26 +84,22 @@
                   <ulink url="http://java.sun.com/products/jta/">JTA</ulink>
                   compliant transaction
                   manager and make any cache
-                  interaction transactional. Note that the cache can also be run without
+                  interaction transactional, and caches would participate in ongoing JTA transactions. Note that the cache can also be run without
                   any replication; this is the local mode.
                </para>
 
-               <para>JBoss Cache comes in two flavours: Core and Pojo versions. The core library
-                  (using the
-                  <literal>org.jboss.cache.Cache</literal>
-                  interface
-                  ) is the underlying library that organises data in a tree-like structure and handles all locking,
+               <para>JBoss Cache comes in two flavours: Core and POJO versions. The core library
+                  (using the <literal>org.jboss.cache.Cache</literal>
+                  interface) is the underlying library that organises data in a tree-like structure and handles all locking,
                   passivation,
-                  eviction and replication characteristics of data in the cache. The pojo library (using the
-                  <literal>org.jboss.cache.pojo.PojoCache</literal>
-                  interface) is built atop the core library and allows introspection
-                  of objects in the cache providing transparent coherence by using JBoss AOP. Note that the Pojo version
+                  eviction and replication characteristics of data in the cache. The POJO library (using the
+                  <literal>org.jboss.cache.pojo.PojoCache</literal> interface) is built atop the core library and allows introspection
+                  of objects in the cache providing transparent coherence by using JBoss AOP. Note that the POJO edition
                   of JBoss Cache
-                  (referred to as PojoCache) comes with a separate set of documentation (user guide, FAQ, etc.)
+                  (often referred to as POJO Cache) comes with a separate set of documentation (user guide, FAQ, etc.)
                   available on the
                   <ulink url="http://labs.jboss.com/portal/jbosscache/docs/index.html">JBoss Cache documentation site
-                  </ulink>
-                  .
+                  </ulink>.
                </para>
 
                <para>
@@ -111,30 +107,17 @@
                   <itemizedlist>
                      <listitem>
                         <para>
-                           <literal>jboss-cache-core</literal>
+                           <literal>jbosscache-core</literal>
                         </para>
                         contains the core Cache library for users who do not wish to use the additional functionality
-                        offered by PojoCache.
+                        offered by POJO Cache.
                      </listitem>
                      <listitem>
                         <para>
-                           <literal>jboss-cache-pojo</literal>
+                           <literal>jbosscache-pojo</literal>
                         </para>
-                        contains the core Cache library as well as the PojoCache extensions and dependencies.
+                        contains the core Cache library as well as POJO Cache extensions and dependencies.
                      </listitem>
-                     <listitem>
-                        <para>
-                           <literal>jboss-cache-all</literal>
-                        </para>
-                        contains all of the above, including unit tests and source code.
-                     </listitem>
-                     <listitem>
-                        <para>
-                           <literal>jboss-cache-core-JDK140</literal>
-                        </para>
-                        contains a JDK 1.4 compatible version of the core Cache library. Note that PojoCache is only
-                        available for JDK 5.0.
-                     </listitem>
                   </itemizedlist>
                </para>
             </answer>
@@ -149,23 +132,21 @@
                <para>
                   JBoss Cache has an active community of developers and contributors. The project was founded by Bela
                   Ban
-                  and is currently led by Manik Surtani. Jason Greene is the lead for the PojoCache subsystem, and other
+                  and is currently led by Manik Surtani. Jason Greene is the lead for the POJO Cache subsystem, and other
                   contributors both past and present include Ben Wang, Harald Gliebe, Brian Stansberry, Vladimir
-                  Blagojevic,
-                  Mircea Markus, Jimmy Wilson, Galder Zamarreño and Elias Ross.
+                  Blagojevic, Mircea Markus, Jimmy Wilson, Galder Zamarreño and Elias Ross.
                </para>
             </answer>
          </qandaentry>
 
          <qandaentry>
             <question>
-               <para>What is the license for JBoss Cache?</para>
+               <para>What about licensing?</para>
             </question>
 
             <answer>
                <para>JBoss Cache is licensed under
-                  <ulink url="http://www.gnu.org/licenses/lgpl.html">LGPL</ulink>
-                  .
+                  <ulink url="http://www.gnu.org/licenses/lgpl.html">LGPL</ulink>, an <ulink url="http://www.opensource.org/">OSI</ulink>-approved open source license.
                </para>
             </answer>
          </qandaentry>
@@ -178,33 +159,22 @@
             <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>
+                  has prebuilt binaries as well as source distributions. You can also grab snapshots from the JBoss.org subversion
+                  repository.  See
+                  <ulink url="http://www.jboss.org/community/docs/DOC-10259">the JBoss Cache development</ulink>
+                  wiki page for details.
                </para>
             </answer>
          </qandaentry>
 
          <qandaentry>
             <question>
-               <para>How do I build JBoss Cache from CVS sources?</para>
+               <para>How do I build JBoss Cache from sources?</para>
             </question>
 
             <answer>
-               <para>To build, do
-                  <literal>sh build.sh
-                     jar
-                  </literal>
-                  . This will produce
-                  <literal>jboss-cache.jar</literal>
-                  and
-                  <literal>pojocache.jar</literal>
-                  in the
-                  <literal>dist/lib</literal>
-                  directory. Note that you will need to
-                  use JDK 5 to build the distribution.
+               <para>
+                  Read the README-Maven.txt file in the source root.  Note that you will need a JDK >= 5.0, and Apache Maven >= 2.0.6.
                </para>
             </answer>
          </qandaentry>
@@ -216,20 +186,12 @@
 
             <answer>
                <para>
-                  JBoss Cache is baselined on Java 5.0 and this is the platform on which JBoss Cache is most thoroughly
-                  tested.
-                  If, for whatever reason you have to use Java 1.4, you could build a retroweaved version of the core
-                  cache
+                  JBoss Cache is baselined on Java 5 and is tested on Java 5 and 6 VMs. If, for whatever reason you have
+                  to use Java 1.4, you could build a retroweaved version of the core cache
                   library that is Java 1.4 compatible, using the simple instructions on this wiki page
-                  <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHabaneroJava1.4">on building and
-                     running JBoss Cache on Java 1.4.
-                  </ulink>
-                  . Note that Red Hat Inc. does not offer commercial support for retroweaved binaries at this stage.
+                  <ulink url="http://www.jboss.org/community/docs/DOC-10263">on building and running JBoss Cache on Java 1.4.
+                  </ulink>.
                </para>
-               <para>
-                  Java 6 should work as well, and we haven't heard of any specific problems of JBoss Cache run under
-                  Java 6.
-               </para>
             </answer>
          </qandaentry>
 
@@ -240,7 +202,7 @@
 
             <answer>
                <para>
-                  <code>java -jar jbosscache.jar</code>
+                  <literal>java -jar jbosscache-core.jar</literal>
                   will spit out version details.
                </para>
             </answer>
@@ -255,11 +217,9 @@
 
             <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
+                  Absolutely! Even though JBoss Cache comes integrated with JBoss Application Server,
+                  it can also be used in any other Java EE server such as BEA WebLogic, IBM Websphere or Tomcat. It
+                  can also run in a standalone Java process, completely outside of an application server. See the user guide for more
                   details.
                </para>
             </answer>
@@ -271,7 +231,7 @@
             </question>
             <answer>
                <para>Look at
-                  <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCache200Migration">this wiki page</ulink>
+                  <ulink url="http://www.jboss.org/community/docs/DOC-10246">this wiki page</ulink>
                   for help.
                </para>
             </answer>
@@ -279,6 +239,28 @@
 
          <qandaentry>
             <question>
+               <para>What about from 2.x to 3.x?</para>
+            </question>
+            <answer>
+               <para>
+                  JBoss Cache 3.x is API compatible with 2.x, although as far as possible you should refactor your code
+                  not to use deprecated methods as these may disappear in future releases of JBoss Cache.
+               </para>
+               <para>
+                  JBoss Cache 3.x comes with an all new configuration format.  Old 2.x configuration files will still
+                  work, although you will get a warning in the logs about this.  Again, as far as possible, we recommend
+                  migrating your configuration file to the new format.  Scripts are provided with the JBoss Cache 3.x
+                  distribution to migrate configuration files (see <literal>config2to3.sh</literal> and <literal>config2to3.bat</literal>).
+               </para>
+               <para>
+                  Note that to take advantage of some of the new features in JBoss Cache 3.x, you need to be using the
+                  new configuration format.
+               </para>               
+            </answer>
+         </qandaentry>
+
+         <qandaentry>
+            <question>
                <para>Where can I report bugs or problems?</para>
             </question>
 
@@ -287,8 +269,7 @@
                   <ulink
                         url="http://jboss.org/index.html?module=bb&amp;op=main&amp;c=29">JBoss Cache
                      User Forum
-                  </ulink>
-                  .
+                  </ulink>.
                </para>
             </answer>
          </qandaentry>
@@ -302,97 +283,19 @@
 
          <qandaentry>
             <question>
-               <para>How do I deploy JBoss Cache as a MBean service?</para>
+               <para>Using JBoss Cache 2 or 3 on JBoss AS 4.x</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/config-samples</literal>
-                  directory, there are example
-                  configuration files for different cache modes that can be used to
-                  deploy JBoss Cache as well.
+               <para>
+                  JBoss AS 4.x ships with JBoss Cache 1.4.x.  To make use of new features, performance improvements
+                  and bug fixes in newer releases, you can follow some of the steps outlined on <ulink url="http://www.jboss.org/community/docs/DOC-10254">this wiki page</ulink>.
                </para>
             </answer>
          </qandaentry>
 
          <qandaentry>
             <question>
-               <para>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 role="JAVA"><![CDATA[
-
-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>
 
@@ -417,23 +320,21 @@
                <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>
+                  <ulink url="http://www.jboss.org/community/docs/DOC-10265">this wiki page</ulink>.
                </para>
             </answer>
          </qandaentry>
 
          <qandaentry>
             <question>
-               <para>What about using Pojo Cache as a Hibernate cache?</para>
+               <para>What about using POJO Cache as a Hibernate cache?</para>
             </question>
 
             <answer>
-               <para>It is not necessary to use PojoCache for second level
+               <para>It is not necessary to use POJO Cache for second level
                   cache inside Hibernate because Hibernate
-                  manages fine-grained fields in Java objects. Using PojoCache won't
-                  provide any advantage.
+                  manages fine-grained fields in Java objects. Using POJO Cache won't
+                  provide any advantage, and will be an unnecessary performance drawback.
                </para>
             </answer>
          </qandaentry>
@@ -456,30 +357,22 @@
 
          <qandaentry>
             <question>
-               <para>In the configuration xml file, there are tags such as
-                  <literal>class</literal>
-                  ,
-                  <literal>MBean</literal>
-                  , etc. What are
-                  these?
+               <para>Can I use a schema or DTD to validate my JBoss Cache configuration file?
                </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>
+                  As of JBoss Cache 3.x, yes.  An XSD schema is provided in your jbosscache-core.jar file, and is also
+                  available online, on <ulink url="http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd">http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd</ulink>.
+                  You can configure your IDE, text editor or XML authoring tool to use this schema to validate your file.
                </para>
             </answer>
          </qandaentry>
 
          <qandaentry>
             <question>
-               <para>What is the difference between the different cache
-                  modes?
+               <para>What is the difference between the different cache modes?
                </para>
             </question>
 
@@ -533,7 +426,10 @@
             <answer>
                <para>JBoss Cache leverages
                   <ulink url="http://www.jgroups.org">JGroups</ulink>
-                  as a replication layer. A user
+                  for network communications.  A JGroups configuration section is present in your JBoss Cache configuration.
+               </para>
+               <para>
+                  A user
                   can configure the cluster of JBoss Cache instances by sharing the
                   same cluster name (
                   <literal>cluster name</literal>
@@ -607,6 +503,13 @@
          </qandaentry>
 
          <qandaentry>
+            <question><para>I'm using Buddy Replication.  Do I need to have some form of session affinity?</para></question>
+            <answer><para>Session affinity relates to returning to the same cache instance for the same data being used.
+               While this is strictly not a requirement for Buddy Replication, it is greatly recommended to minimize
+               moving state around a cluster.</para></answer>
+         </qandaentry>
+
+         <qandaentry>
             <question>
                <para>If I have the need for different configuration properties (e.g.,
                   <literal>CacheMode</literal>
@@ -642,6 +545,10 @@
                   a single JGroups channel. Please see the User Guide for details on how to configure the JGroups
                   Multiplexer.
                </para>
+               <para>
+                  A faster and more efficient approach is to use a shared transport in JGroups.  Please see                   
+                  <ulink url="http://www.jgroups.org">the JGroups documentation</ulink> for more details on how to do this.
+               </para>
             </answer>
          </qandaentry>
 
@@ -747,16 +654,13 @@
             <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
+                  compliant such as <ulink url="http://www.jboss.org/jbosstm/">JBoss Transactions</ulink>.
+                  </para>
+               <para>
+                  While JBoss Cache does ships with a
                   dummy transaction manager
-                  (
-                  <literal>org.jboss.cache.transaction.DummyTransactionManager</literal>
-                  ) 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.
+                  (<literal>org.jboss.cache.transaction.DummyTransactionManager</literal>), we do <emphasis>not</emphasis>
+                  recommend using this for production.  It is not thread safe, and is intended for internal testing only.
                </para>
             </answer>
          </qandaentry>
@@ -783,7 +687,11 @@
                   cache will look up the transaction context from this transaction
                   manager.
                </para>
-
+               <para>
+                  The <literal>org.jboss.cache.transaction.GenericTransactionManagerLookup</literal> class that ships
+                  with JBoss Cache is able to detect and bind to most popular transaction managers.  See the <literal>GenericTransactionManagerLookup</literal>
+                  javadocs for more information.
+               </para>
             </answer>
          </qandaentry>
 
@@ -814,6 +722,11 @@
                   to the
                   user manual.
                </para>
+               <para>
+                  As of JBoss Cache 3.x, when using the MVCC locking scheme, only <literal>READ_COMMITTED</literal> and
+                  <literal>REPEATABLE_READ</literal> are supported.  Any other isolation level provided will either be upgraded
+                  or downgraded accordingly.
+               </para>
             </answer>
          </qandaentry>
 
@@ -823,35 +736,16 @@
             </question>
 
             <answer>
-               <para>By default JBoss Cache uses pessimistic locking to lock data nodes, based on the isolation level
+               <para>In JBoss Cache 2.x, by default pessimistic locking is used to lock data nodes, based on the isolation level
                   configured. We also offer optimistic locking to allow for greater concurrency
                   at
                   the cost of slight processing overhead and performance. See the documentation for a more detailed
                   discussion on concurrency and locking in JBoss Cache.
                </para>
-            </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>
+                  In JBoss Cache 3.x, optimistic and pessimistic locking are deprecated in favour of MVCC (multi-version concurrency
+                  control), which is far more efficient than either optimistic or pessimistic locking.  For a detailed discussion on
+                  our MVCC implementation, see <ulink url="http://jbosscache.blogspot.com/2008/07/mvcc-has-landed.html">this blog entry</ulink> and <ulink url="http://www.jboss.org/community/docs/DOC-10272">this wiki page</ulink>.
                </para>
             </answer>
          </qandaentry>
@@ -859,26 +753,13 @@
 
          <qandaentry>
             <question>
-               <para>How does the write lock apply to an Fqn node, say,
-                  "/org/jboss/test"?
-               </para>
+               <para>How do I enable Optimistic Locking or MVCC in JBoss Cache?</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>
+                  Please see the configuration section of the user guide for details.
                </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>
 
@@ -914,8 +795,7 @@
                   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).
+                  has performance implications if network latency is a problem.
                </para>
             </answer>
          </qandaentry>
@@ -926,7 +806,7 @@
             </question>
 
             <answer>
-               <para>If you do a cache.removeNode(Fqn.fromString("/myroot")), it will recursively remove
+               <para>If you do a <literal>cache.removeNode("/myroot")</literal>, it will recursively remove
                   all the entries under "/myroot".
                </para>
             </answer>
@@ -953,15 +833,7 @@
             </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>Yes, you can. See the section on configuration in the JBoss Cache user guide.
                </para>
             </answer>
          </qandaentry>
@@ -991,13 +863,16 @@
                   different cache instances while still participating as a replication
                   group.
                </para>
+               <para>
+                  This is on the roadmap though, so do keep an eye on <ulink url="http://jira.jboss.org/jira/browse/JBCACHE-60">JBCACHE-60</ulink> if you are interested.
+               </para>
             </answer>
          </qandaentry>
 
          <qandaentry>
             <question>
                <para>Does JBoss Cache handle the concept of application classloading
-                  inside, say, a J2EE container?
+                  inside, say, a Java EE container?
                </para>
             </question>
 
@@ -1046,60 +921,11 @@
                   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>To solve the second kind of issue,  you can use the the <literal>UseLazyDeserialization</literal> configuration
+                  option in JBoss Cache, which wraps your objects in a <literal>Marshalledvalue</literal> wrapper.  The <literal>MarshalledValue</literal>
+                  serializes and deserializes your object on demand, ensuring the proper thread local context class loader is used each time.
                </para>
-
-               <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 role="JAVA">
-                  <![CDATA[
-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>
+         </answer>
          </qandaentry>
 
          <qandaentry>
@@ -1113,8 +939,8 @@
                <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.
+                  <literal>org.jboss.cache.notifications.annotations.CacheListener</literal>
+                  annotation for details.
                </para>
             </answer>
          </qandaentry>
@@ -1128,13 +954,7 @@
 
             <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.
+                  See the user guide on this subject.
                </para>
             </answer>
          </qandaentry>
@@ -1203,7 +1023,7 @@
             <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.
+                  guide for details.
                </para>
             </answer>
          </qandaentry>
@@ -1281,72 +1101,6 @@
 
          <qandaentry>
             <question>
-               <para>What are the
-                  <literal>EvictionPolicyConfig</literal>
-                  tag
-                  parameters for
-                  <literal>org.jboss.cache.eviction.LRUPolicy</literal>
-                  ?
-               </para>
-            </question>
-
-            <answer>
-               <para>They are:</para>
-
-               <table>
-                  <title>Parameters</title>
-
-                  <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>
-
-         <qandaentry>
-            <question>
                <para>I have turned on the eviction policy, why do I still get "out
                   of memory" (OOM) exception?
                </para>
@@ -1356,18 +1110,15 @@
                <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
+                  <literal>wakeUpInterval</literal> milliseconds (or <literal>wakeUpIntervalSeconds</literal> seconds, prior to 3.x)
+                  to process the eviction event queue. So when the queue size is full, it will create a
                   backlog and cause out-of-memory exceptions to happen unless the eviction timer catches
                   up. To address this problem, in addition to increase the VM heap
                   size, you can also reduce the
-                  <literal>wakeUpIntervaleInSeconds</literal>
+                  <literal>wakeUpInterval</literal>
                   so the timer thread
                   processes the queue more frequently.
                </para>
-
-               <para>The eviction queue size is configurable.
-               </para>
             </answer>
          </qandaentry>
       </qandaset>
@@ -1419,15 +1170,21 @@
 
                      <listitem>
                         <para>
-                           <literal>org.jboss.cache.loader.BdbjeCacheLoader</literal>
+                           <literal>org.jboss.cache.loader.jdbm.JdbmCacheLoader</literal>
+                           : this implementation is based on <ulink url="http://jdbm.sourceforge.net/">JDBM</ulink>,
+                           an open source file-based transactional persistence engine.
+                        </para>
+                     </listitem>
+
+                     <listitem>
+                        <para>
+                           <literal>org.jboss.cache.loader.bdbje.BdbjeCacheLoader</literal>
                            : this implementation is based on the
                            Oracle's Berkeley DB Java Edition database, a fast and efficient
                            transactional database. It uses a single file for the entire
                            store. Note that if you use the Berkeley DB cache loader with
                            JBoss Cache and wish to ship your product, you will have to acquire a
-                           <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from Oracle
-                           </ulink>
-                           .
+                           <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from Oracle</ulink>.
                         </para>
                      </listitem>
 
@@ -1641,7 +1398,7 @@
             </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>
+                  <ulink url="http://www.jboss.org/community/docs/DOC-10288">wiki link</ulink>
                   .
                </para>
             </answer>




More information about the jbosscache-commits mailing list