Menu
▾
▴
[jboss-cvs] jboss-cache/docs FAQ.xml
|
From: Ben W. <bw...@us...> - 2004-11-05 07:33:54
|
User: bwang00
Date: 04/11/04 23:33:46
Modified: docs FAQ.xml
Log:
Updated for 1.2 release
Revision Changes Path
1.13 +164 -57 jboss-cache/docs/FAQ.xml
Index: FAQ.xml
===================================================================
RCS file: /cvsroot/jboss/jboss-cache/docs/FAQ.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- FAQ.xml 31 Aug 2004 06:55:27 -0000 1.12
+++ FAQ.xml 5 Nov 2004 07:33:46 -0000 1.13
@@ -21,7 +21,7 @@
<email>be...@jb...</email>
</author>
- <pubdate>August, 2004</pubdate>
+ <pubdate>November, 2004</pubdate>
</articleinfo>
<para>This is frequently asked questions regarding to JBossCache.</para>
@@ -48,7 +48,7 @@
TreeCache is a tree-structured cache that provides replication and
transaction context, while TreeCacheAop extends the functionality of
TreeCache but behaves as a true object cache providing transparent
- object mapping into internal cache.</para>
+ and finer-grained object mapping into internal cache.</para>
</answer>
</qandaentry>
@@ -92,13 +92,15 @@
</question>
<answer>
- <para>You will need to get jboss-head first from sourceforge.net
- using anonymous cvs. After doing a full build of JBoss, if you want
- to build the library under JBoss, do <literal>sh build.sh</literal>.
- This will produce <literal>jboss-cache.jar</literal>. Or if you want
- to build the standalone package, do <literal>sh build.sh
- dist</literal> this will produce
- <literal>jboss-cache-dist.zip.</literal></para>
+ <para>You will need to get jboss-head source first from
+ www.sourceforge.net using anonymous cvs. After doing a full build of
+ JBoss (execute <literal>build</literal> under build directory)), if
+ you want to build the library under JBoss, do <literal>sh
+ build.sh</literal> in the cache directory. This will produce
+ <literal>jboss-cache.jar</literal> in the <literal>lib</literal>
+ directory. Or if you want to build the standalone package, do
+ <literal>sh build.sh dist</literal> this will produce
+ <literal>jboss-cache-dist.zip</literal>.</para>
</answer>
</qandaentry>
@@ -110,7 +112,7 @@
<answer>
<para>JBossCache has been tested and supported on JDK1.4. On
jboss-3.2 cvs tree, it also compiles on JDK1.3, but there is no
- official support for it though.</para>
+ official support for it though. We will support JDK1.5 soon.</para>
</answer>
</qandaentry>
@@ -215,7 +217,7 @@
<answer>
<para>You can configure the JBossCache through a configuration xml
file. Or you can set it programatically through its get/set methods.
- Check with the documenation for both examples.</para>
+ Check with the documentation for both examples.</para>
</answer>
</qandaentry>
@@ -441,6 +443,37 @@
<qandaentry>
<question>
+ <para>Can I use the cache locking level even without a transaction
+ context?</para>
+ </question>
+
+ <answer>
+ <para>Yes. JBossCache controls the individual node locking behavior
+ through the isolation level semantics. This means even if you don't
+ use a transaction, you can specify the lock level via isolation
+ level. You can think of the node locking behavior outside of a
+ transaction as if it is under transaction with
+ <literal>auto_commit</literal> on.</para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>During replication mode (e.g., REPL_SYNC and REPL_ASYNC), how
+ often does the cache do the replication?</para>
+ </question>
+
+ <answer>
+ <para>If the updates are under transaction, then the replication
+ happens only when the transaction is about to commit (actually
+ during the prepare stage internally). That is, it will be a batch
+ update. However, if the operations are not under transaction
+ context, then each update will trigger replication.</para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
<para>Can I monitor and manage the JBossCache?</para>
</question>
@@ -549,16 +582,17 @@
<answer>
<para>TreeCacheAop (currently implemented as a sub-class of
- TreeCache) is a replicated and transactional "object-oriented"
- cache. By "object-oriented", we mean that the cache: 1)
- automatically manages object mapping and relationship for a client
- under both local and replicated cache mode, 2) provides support for
- inheritance relationship between "advised" POJOs. By leveraging the
- dynamic AOP in JBossAop, it is able to map a complex object into the
- cache store, preserve and 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>
+ TreeCache) is a fine-grained field-level replicated and
+ transactional "object-oriented" cache. By "object-oriented", we mean
+ that the cache: 1) automatically manages object mapping and
+ relationship for a client under both local and replicated cache
+ mode, 2) provides support for inheritance relationship between
+ "advised" POJOs. By leveraging the dynamic AOP in JBossAop, it is
+ able to map a complex object into the cache store, preserve and
+ 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>
<para>From a user perspective, once the object is managed by the
cache, all cache operations are transparent. Therefore, all the
@@ -593,14 +627,14 @@
<para>Think of TreeCacheAop as a TreeCache on steroid. :-)
Seriously, both are cache store. However, while TreeCache only
provides pure object reference storage (e.g., <literal>put(FQN fqn,
- Objecy key, Object value)</literal>), TreeCacheAop goes behind that
- and performs object mapping and relationship management for a user
- behind the scene. As a result, if you have a complex object systems
- that you would like to cache, you can have TreeCacheAop manages 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>
+ Objecy key, Object value)</literal>), TreeCacheAop goes beyond that
+ and performs fine-grained field level replication object mapping and
+ relationship management for a user behind the scene. As a result, if
+ you have a complex object systems that you would like to cache, you
+ can have TreeCacheAop manages 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>
</answer>
</qandaentry>
@@ -653,13 +687,14 @@
<answer>
<para>Yes, you can use TreeCacheAop to do that. It supports the
- notion of object reference.</para>
+ notion of object reference. TreeCacheAop manages the unique object
+ through association of the dynamic cache interceptor.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
- <para>Do I need to declare all my objects "prepare" in
+ <para>Do I need to declare all my objects "prepared" in
<literal>jboss-aop.xml</literal>?</para>
</question>
@@ -668,7 +703,68 @@
the cache to manage it 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 though.</para>
+ <literal>Serializable</literal> interface for replication
+ though.</para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>Can the cache aop intercept update via reflection?</para>
+ </question>
+
+ <answer>
+ <para>The update via reflection will not be intercepted in JBossAop
+ and therefore TreeCacheAop will not be able to perform the necessary
+ synchronization.</para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>When I declared my POJO to be "advised", what happens to the
+ fields with transient, static, and final modifiers?</para>
+ </question>
+
+ <answer>
+ <para>TreeCacheAop 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>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>What are those keys such as
+ <literal>JBoss:internal:class</literal> and
+ <literal>AOPInstance</literal>?</para>
+ </question>
+
+ <answer>
+ <para>They are for internal use only. User should ignore these key
+ and values in the node hashmap.</para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>What about Collection classes? Do I need to declared them
+ "prepared"?</para>
+ </question>
+
+ <answer>
+ <para>No. Since the Collection classes such as
+ <literal>ArrayList</literal> are java util classes, aop by default
+ won't instrument these classes. Instead, TreeCacheAop will generate
+ a dynamic class proxy for the Collection classes. 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 TreeCacheAop.</para>
+
+ <para>Internally, the cache interceptor implements the APIs by
+ direct interaction with respect to the underlying cache store. Note
+ that this can have implication in performance for certain APIs. Plan
+ is underway to optimize these APIs.</para>
</answer>
</qandaentry>
@@ -681,15 +777,15 @@
<answer>
<para>TreeCacheAop supports classes extends from
<literal>List</literal>, <literal>Set</literal>, and
- <literal>Map</literal> without users to declare it "advised". It is
- done via a dynamic proxy. Here is a code snippet to use an
- <literal>ArrayList</literal> class.</para>
+ <literal>Map</literal> without users to declare them "advised". It
+ is done via a dynamic proxy. Here is a code snippet to use an
+ <literal>ArrayList</literal> proxy class.</para>
<programlisting>ArrayList list = new ArrayList();
list.add("first");
-cache.putObject("/list/test", list);
-list.add("second"); // Won't work since AOP intercept 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
@@ -697,6 +793,25 @@
myList.remove("third");</programlisting>
</answer>
</qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>What happen when my "advised" POJO has field members that 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
+ members into the cache store as well. When the field member is of a
+ Collection class (e.g., List, Set, or Map), TreeCacheAop will first
+ map the collection into cache. Then, it will swap out dynamically
+ 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>
+ </answer>
+ </qandaentry>
</qandadiv>
<qandadiv>
@@ -836,7 +951,7 @@
<qandaentry>
<question>
<para>I have turned on the eviction policy, why do I still get "out
- of memeory" (OOM) exception?</para>
+ of memory" (OOM) exception?</para>
</question>
<answer>
@@ -862,7 +977,7 @@
<qandaentry>
<question>
- <para>What is a CacheLoader ?</para>
+ <para>What is a CacheLoader?</para>
</question>
<answer>
@@ -880,7 +995,7 @@
all configured through XML, and the programmer doesn't have to take
care of loading and eviction.</para>
- <para>JBossCache currently (July 2004) ships with 2 CacheLoader
+ <para>JBossCache currently ships with 3 CacheLoader
implementations:</para>
<para><itemizedlist>
@@ -902,19 +1017,11 @@
linkend="???">http://www.sleepycat.com/jeforjbosscache</link>
for details.</para>
</listitem>
- </itemizedlist></para>
- </answer>
- </qandaentry>
- <qandaentry>
- <question>
- <para>Are there other CacheLoaders ?</para>
- </question>
-
- <answer>
- <para>We plan to write a DB CacheLoader, using either JDBC, or an
- O/R mapper such as Hibernate. Once in place, JBossCache will be able
- to interface with relational databases.</para>
+ <listitem>
+ JDBCCacheLoader: this implementation uses the relational database as the persistent storage.
+ </listitem>
+ </itemizedlist></para>
</answer>
</qandaentry>
@@ -948,7 +1055,7 @@
<qandaentry>
<question>
- <para>What can I use a CacheLoader for ?</para>
+ <para>What can I use a CacheLoader for?</para>
</question>
<answer>
@@ -965,8 +1072,8 @@
</listitem>
<listitem>
- <para>Simple persistence for POJOs. Use of JBossCacheAop and a
- local CacheLoader persist POJOs transparently into the store
+ <para>Simple persistence for POJOs. Use of JBossCache aop and
+ a local CacheLoader persist POJOs transparently into the store
provided by the CacheLoader.</para>
</listitem>
@@ -991,7 +1098,7 @@
<qandaentry>
<question>
- <para>How do I configure JBossCache with a CacheLoader ?</para>
+ <para>How do I configure JBossCache with a CacheLoader?</para>
</question>
<answer>
@@ -1004,7 +1111,7 @@
<qandaentry>
<question>
- <para>Do I have to pay to use Sleepycat's CacheLoader ?</para>
+ <para>Do I have to pay to use Sleepycat's CacheLoader?</para>
</question>
<answer>
|