[jboss-cvs] JBossCache/docs/faq-pojo/en ...
Manik Surtani
manik at jboss.org
Tue Apr 17 03:44:47 EDT 2007
User: msurtani
Date: 07/04/17 03:44:47
Modified: docs/faq-pojo/en master.xml
Log:
updated release date
Revision Changes Path
1.6 +749 -568 JBossCache/docs/faq-pojo/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-pojo/en/master.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -b -r1.5 -r1.6
--- master.xml 22 Nov 2006 04:32:02 -0000 1.5
+++ master.xml 17 Apr 2007 07:44:47 -0000 1.6
@@ -1,12 +1,12 @@
<?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 PojoCache</title>
<releaseinfo>Release 2.0.0</releaseinfo>
- <pubdate>January 2007</pubdate>
+ <pubdate>June 2007</pubdate>
<author>
<firstname>Ben</firstname>
@@ -42,16 +42,20 @@
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
usual in-VM POJO method semantics are still preserved, providing
ease of use. For example, if a POJO has been put in PojoCache (by
- calling <literal>attach</literal>, for example), then any POJO get/set
+ calling
+ <literal>attach</literal>
+ , for example), then any POJO get/set
method will be
intercepted by PojoCache to provide the data from the
- cache.</para>
+ cache.
+ </para>
</answer>
</qandaentry>
@@ -61,32 +65,43 @@
</question>
<answer>
- <para>The core JBoss Cache library <literal>Cache</literal> is a traditional generic distributed cache system.
- PojoCache uses Cache as the underlying distributed state system to achieve POJO caching. It uses Cache as a
+ <para>The core JBoss Cache library
+ <literal>Cache</literal>
+ is a traditional generic distributed cache system.
+ PojoCache uses Cache as the underlying distributed state system to achieve POJO caching. It uses Cache as
+ a
delegate. As a result, all the replication aspects are configured with the Cache configuration XML.
- Additionally, PojoCache also has API to expose the Cache interface (via <literal>getCache()</literal> API).</para>
+ Additionally, PojoCache also has API to expose the Cache interface (via
+ <literal>getCache()</literal>
+ API).
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="a52">
<para>What is the difference between Cache and
- PojoCache?</para>
+ PojoCache?
+ </para>
</question>
<answer>
<para>Think of PojoCache as a Cache on steroids. :-)
Seriously, both are cache stores-- one is a generic cache and the other other one POJO Cache.
However, while Cache 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>
@@ -97,7 +112,10 @@
<answer>
<para>PojoCache uses the so-called AOP technology (aspect oriented programming) to do field level
- interception. Currently, it uses <literal>JBoss Aop</literal> library to do it.</para>
+ interception. Currently, it uses
+ <literal>JBoss Aop</literal>
+ library to do it.
+ </para>
</answer>
</qandaentry>
@@ -107,25 +125,45 @@
</question>
<answer>
- <para>Starting in 2.0 release, we have a separate library for PojoCache, <literal>pojocache.jar</literal> that
- is extra to the core <literal>jboss-cache.jar</literal>. Since we uses Cache as a delegate, user
+ <para>Starting in 2.0 release, we have a separate library for PojoCache,
+ <literal>pojocache.jar</literal>
+ that
+ is extra to the core
+ <literal>jboss-cache.jar</literal>
+ . Since we uses Cache as a delegate, user
will need to have a regular xml to configure the core Cache functionality (e.g., replication and locking
- aspect). In addition, there is also the <literal>pojocache-aop.xml</literal> that specifies the PojoCache
- interceptor stack (that can be left as default).</para>
+ aspect). In addition, there is also the
+ <literal>pojocache-aop.xml</literal>
+ that specifies the PojoCache
+ interceptor stack (that can be left as default).
+ </para>
<para>Additionally, here are the changed features:
<itemizedlist>
<listitem>
- <para>New APIs. It replaces <literal>putObject, removeObject, and get</literal> with
- <literal>attach, detach, and find</literal>.</para></listitem>
+ <para>New APIs. It replaces
+ <literal>putObject, removeObject, and get</literal>
+ with
+ <literal>attach, detach, and find</literal>
+ .
+ </para>
+ </listitem>
<listitem>
- <para>New POJO based events that a user can subscribe to.</para></listitem>
+ <para>New POJO based events that a user can subscribe to.</para>
+ </listitem>
<listitem>
<para>New configuration pojocache-aop.xml specifically for PojoCache, in addition to
- the regular cache-service.xml for the delegating Cache.</para></listitem>
+ the regular cache-service.xml for the delegating Cache.
+ </para>
+ </listitem>
<listitem>
- <para>New package namespace (<literal>org.jboss.cache.pojo)</literal> for PojoCache.
- The previous <literal>org.jboss.cache.aop</literal> space has been deprecated.
- </para></listitem>
+ <para>New package namespace (
+ <literal>org.jboss.cache.pojo)</literal>
+ for PojoCache.
+ The previous
+ <literal>org.jboss.cache.aop</literal>
+ space has been deprecated.
+ </para>
+ </listitem>
</itemizedlist>
</para>
</answer>
@@ -140,18 +178,31 @@
<para>In order to use PojoCache, you will need to:</para>
<itemizedlist>
- <listitem><para>prepare POJO. You can do either via xml declaration or JDK50 annotation.
+ <listitem>
+ <para>prepare POJO. You can do either via xml declaration or JDK50 annotation.
This is the step to declare your POJO such that it will be instrumented by
- <literal>JBoss Aop</literal>.</para></listitem>
- <listitem><para>instrumentation. You will need to instrument your POJO either at compile- or load-time.
- If you do it during compile-time, you use so-called an 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. Either way, <literal>JBoss Aop</literal> will byte code manipulate your POJO
- class such that all field access can be intercepted.</para></listitem>
+ <literal>JBoss Aop</literal>
+ .
+ </para>
+ </listitem>
+ <listitem>
+ <para>instrumentation. You will need to instrument your POJO either at compile- or load-time.
+ If you do it during compile-time, you use so-called an 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. Either way,
+ <literal>JBoss Aop</literal>
+ will byte code manipulate your POJO
+ class such that all field access can be intercepted.
+ </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>
@@ -172,7 +223,8 @@
<answer>
<para>Yes, same as the core Cache library, you can run PojoCache either as a standalone or
- inside an application server.</para>
+ inside an application server.
+ </para>
</answer>
</qandaentry>
@@ -183,42 +235,59 @@
<answer>
<para>PojoCache can be run either in AS4.0.5 (and up) and 5.0. But either way, it will require
- JDK5.0 though.</para>
+ JDK5.0 though.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="a56">
<para>Can I pre-compile the aop classes such that I don't need to
- use the system classloader and jboss-aop configuration xml during runtime?</para>
+ use the system classloader and jboss-aop configuration xml during runtime?
+ </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>aopc</literal>. In addition, please also check out the
- <literal>examples</literal> directory for concrete examples.</para>
+ <literal>aopc</literal>
+ . In addition, please also check out the
+ <literal>examples</literal>
+ directory for concrete examples.
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="a561">
- <para>In PojoCache 2.x release, do I still need <literal>annoc</literal>?</para>
+ <para>In PojoCache 2.x release, do I still need
+ <literal>annoc</literal>
+ ?
+ </para>
</question>
<answer>
<para>The annoc precompiler is needed for JDK1.4 style annotation. For 2.x release, since
- we require the use of JDK5.0, there is no need to use annoc anymore.</para>
+ we require the use of JDK5.0, there is no need to use annoc anymore.
+ </para>
</answer>
</qandaentry>
@@ -230,7 +299,8 @@
<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>
@@ -243,42 +313,64 @@
<para>Yes, since 2.0, you can use PojoCacheListener to subscribe to events
such as POJO attach and detach and field updates. And if you need some customization,
you can also use the Obervable pattern directly. TO see an example, please check
- out the test case: <literal>org.jboss.cache.pojo.observer.LocalTest.java</literal></para>
+ out the test case:
+ <literal>org.jboss.cache.pojo.observer.LocalTest.java</literal>
+ </para>
</answer>
</qandaentry>
<qandaentry>
<question id="a58">
- <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.pojo.interceptor.dynamic.CacheFieldInterceptor</literal> to this POJO
- to perform object mapping and relationship management.</para>
+ <literal>org.jboss.cache.pojo.interceptor.dynamic.CacheFieldInterceptor</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>
<qandaentry>
<question id="a58a">
- <para>What's the difference between <literal>jboss-aop.xml</literal>
- <literal>pojocache-aop.xml</literal>?</para>
+ <para>What's the difference between
+ <literal>jboss-aop.xml</literal>
+ <literal>pojocache-aop.xml</literal>
+ ?
+ </para>
</question>
<answer>
- <para><literal>pojocache-aop.xml</literal> is essentially a <literal>jboss-aop.xml</literal>,
+ <para>
+ <literal>pojocache-aop.xml</literal>
+ is essentially a
+ <literal>jboss-aop.xml</literal>
+ ,
except it is used specifically for PojoCache. The analogy is similar to JBoss' own
- MBean service file <literal>jboss-service.xml</literal>, for example. So in our documentation,
+ MBean service file
+ <literal>jboss-service.xml</literal>
+ , for example. So in our documentation,
we will use these two terms interchangeably.
</para>
</answer>
@@ -291,7 +383,8 @@
<answer>
<para>Yes, in release 2.0, you can use JDK5.0 annotation to
- instrument your POJO. Check the documentation for details.</para>
+ instrument your POJO. Check the documentation for details.
+ </para>
</answer>
</qandaentry>
@@ -304,24 +397,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="a61">
- <para>What are the <literal>@org.jboss.cache.pojo.annotation.Transient</literal> and
- <literal>@org.jboss.cache.pojo.annotation.Serializable</literal> field level annotations?</para>
+ <para>What are the
+ <literal>@org.jboss.cache.pojo.annotation.Transient</literal>
+ and
+ <literal>@org.jboss.cache.pojo.annotation.Serializable</literal>
+ field level annotations?
+ </para>
</question>
<answer>
<para>In 2.0, we also offer two additional field-level annotations. The first one,
- <literal>@org.jboss.cache.pojo.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>@org.jboss.cache.pojo.Serializable</literal> when applied,
+ <literal>@org.jboss.cache.pojo.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>@org.jboss.cache.pojo.Serializable</literal>
+ when applied,
will cause PojoCache to
- treat the field as a Serializable object even when it is <literal>@org.jboss.cache.pojo.Replicable</literal>.
+ treat the field as a Serializable object even when it is
+ <literal>@org.jboss.cache.pojo.Replicable</literal>
+ .
</para>
</answer>
</qandaentry>
@@ -333,36 +439,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="a63">
<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="a64">
<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>
@@ -374,109 +488,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="a66">
<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="a67">
<para>What are those keys such as
- <literal>JBoss:internal:class</literal> and
- <literal>PojoInstance</literal>?</para>
+ <literal>JBoss:internal:class</literal>
+ and
+ <literal>PojoInstance</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="a68">
<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>attach</literal> call is invoked). The proxy will
+ <literal>attach</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="a69">
- <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.attach("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.attach("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.find("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.find("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="a70">
<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.attach("list", list); // Put the list under the aop cache
+ cache.attach("list", list); // Put the list under the aop cache
-ArrayList myList = (List)cache.find("list"); // we are getting a dynamic proxy instead
-myList.add("second"); // it works now
+ ArrayList myList = (List)cache.find("list"); // we are getting a dynamic proxy instead
+ myList.add("second"); // it works now
-cache.attach("list_alias", myList); // Note you will need to use the proxy here!!
-myList.remove("second");</programlisting>
+ cache.attach("list_alias", myList); // Note you will need to use the proxy here!!
+ myList.remove("second");
+ </programlisting>
</answer>
</qandaentry>
@@ -485,7 +633,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>
@@ -493,26 +643,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="a72">
<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>attach</literal>, it will recursively map the field
+ <literal>attach</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>
@@ -525,7 +680,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.
@@ -534,8 +690,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>
@@ -550,26 +708,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 "attach" and "detach" 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 "attach" and "detach" often, it will be slow in performance.
+ </para>
+ </listitem>
</itemizedlist>
</answer>
</qandaentry>
@@ -603,7 +782,8 @@
when the item needs to be accessed again, we will retrieve it from the cache store.
</para>
<para>In this sense, PojoCache level is not aware of the passivation aspect. It is configured through
- the underlying cache xml.</para>
+ the underlying cache xml.
+ </para>
</answer>
</qandaentry>
</qandaset>
@@ -616,7 +796,8 @@
</question>
<answer>
<para>Troubleshooting section can be found in the following
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=PojoCacheTroubleshooting">wiki link</ulink>.
+ <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=PojoCacheTroubleshooting">wiki link</ulink>
+ .
</para>
</answer>
</qandaentry>
More information about the jboss-cvs-commits
mailing list