[jboss-cvs] jboss-cache/docs/html FAQ.html

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

  User: bwang00 
  Date: 04/03/21 10:48:45

  Modified:    docs/html FAQ.html
  Log:
  Updated for release 1.0
  
  Revision  Changes    Path
  1.3       +10 -1     jboss-cache/docs/html/FAQ.html
  
  Index: FAQ.html
  ===================================================================
  RCS file: /cvsroot/jboss/jboss-cache/docs/html/FAQ.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- FAQ.html	19 Mar 2004 07:40:41 -0000	1.2
  +++ FAQ.html	21 Mar 2004 18:48:45 -0000	1.3
  @@ -7,4 +7,13 @@
   
   tx.begin()
   tree.put(fqn, key, value);
  -tx.commit();</pre></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e245"></a><a name="d0e246"></a><b>Q:</b></td><td align="left" valign="top"><p>How do I control the cache locking level?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>JBossCache let you control the cache locking level through the transaction isolation level. This is configured through the attribute <tt class="literal">IsolationLevel</tt>. Currently, JBossCache employs pessimistic locking internally. And the transaction isolation level from the pessimist locking corresponds to JDBC isolation levels, namely, <tt class="literal">NONE</tt>, <tt class="literal">READ_UNCOMMITTED</tt>, <tt class="literal">READ_COMMITTED</tt>, <tt class="literal">REPEATABLE_READ</tt>, and <tt class="literal">SERIALIZABLE</tt>. For details, please refer to the user manual.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e270"></a><a name="d0e271"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache support eviction policy?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. JBossCache currently implements a LRU eviction policy for both TreeCache (<tt class="literal">org.jboss.cache.eviction.LRUPolicy</tt>) and TreeCacheAop (<tt class="literal">org.jboss.cache.eviction.AopLRUPolicy</tt>). Users can also plug in their own eviction policy algorithms. See user manual for details.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e283"></a><a name="d0e284"></a><b>Q:</b></td><td align="left" valign="top"><p>Why can't I use <tt class="literal">org.jboss.cache.eviction.LRUPolicy</tt> for TreeCacheAop as well?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>For TreeCacheAop, you will need to use <tt class="literal">org.jboss.cache.eviction.AopLRUPolicy</tt>) because AOP has its eviction algorithm, although is LRU but has totally different notion of an "object", for example.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e296"></a><a name="d0e297"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache's implemented LRU eviction policy operates in replication mode?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes and no. :-)</p><p>The LRU policy only operates in local mode. That is, nodes that are only evicted locally. This may cause the cache contents not to be synchronized temporarily. But when a user tries to obtain a cache content of an evicted node and finds out that is null (e.g., get returns null), it should get it from 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.</p><p>However, you still can run eviction policy with cache mode set to either <tt class="literal">REPL_SYNC</tt> or <tt class="literal">REPL_ASYNC</tt>. Depends on your use case, you can set multiple cache instances to have their own eviction policy (of which is operated locally) or just have selected instance with eviction policy activated.</p><p>Also note that, when the cache persistence layer is implemented in the next release, an locally evicted node can also be persisted to the backend store.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e315"></a><a name="d0e316"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache support <tt class="literal">Region</tt>?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. JBossCache has the notion of region where a user can configure the eviction policy parameters (e.g., <tt class="literal">maxNodes</tt> or <tt class="literal">timeToIdelSeconds</tt> )</p><p>A region in JBossCache denotes a portion of tree hierarchy, e.g., a fully qualified name (<tt class="literal">FQN</tt>). For example, a user can define <tt class="literal">/org/jboss</tt> and <tt class="literal">/org/foocom</tt> as two separate regions.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e342"></a><a name="d0e343"></a><b>Q:</b></td><td align="left" valign="top"><p>Can I monitor and manage the JBossCache?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>If you are running JBossCache as a MBean service inside JBoss, you can monitor and manage through the jmx console. We plan to add more attributes such as cache hit/miss numbers in the future release.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e349"></a><a name="d0e350"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache support partitioning?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Not right now. JBossCache 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.</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><a name="d0e356"></a><h3 class="title"><a name="d0e356"></a>3. TreeCacheAop</h3></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e359"></a><a name="d0e360"></a><b>Q:</b></td><td align="left" valign="top"><p>What is TreeCacheAop?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>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.</p><p>From a user perspective, once the object 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 TreeCacheAop (by calling putObject, for example), then any get/set method will be intercepted by TreeCacheAop to provide the data from the cache.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e368"></a><a name="d0e369"></a><b>Q:</b></td><td align="left" valign="top"><p>Does TreeCacheAop have all the functional capabilities of TreeCache?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. TreeCacheAop extends TreeCache so it has all the same features TreeCache such as cache mode, transaction isolation level, and eviction policy.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e375"></a><a name="d0e376"></a><b>Q:</b></td><td align="left" valign="top"><p>What is the difference between TreeCache and TreeCacheAop?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Think of TreeCacheAop as a TreeCache on steroid. :-) Seriously, both are cache store. However, while TreeCache only provides pure object reference storage (e.g., <tt class="literal">put(FQN fqn, Objecy key, Object value)</tt>), 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.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e385"></a><a name="d0e386"></a><b>Q:</b></td><td align="left" valign="top"><p>Can I pre-compile the aop classes such that I don't need to use the system classloader and jboss-aop configuration xml?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. The latest versions of JBossCache has a per-compiler option called <tt class="literal">aopc</tt>. You can use this option to pre-compile your "advised" POJO. Once the classes have been byte code generated, it can be treated as regular class files, i.e., you will not need to include any <tt class="literal">jboss-aop.xml</tt> that specifies the advisable POJO and to specify the JBossAop system class loader.</p><p>For an example of how to use <tt class="literal">aopc</tt>, please see the <tt class="literal">build.xml</tt> in the standalone package.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e406"></a><a name="d0e407"></a><b>Q:</b></td><td align="left" valign="top"><p>What's in the <tt class="literal">jboss-aop.xml</tt> configuration?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>In <tt class="literal">jboss-aop.xml</tt>, you declare your POJO (e.g., <tt class="literal">Person</tt> to be "prepared", a JBOssAop term to denote that the object will be "advised" by the system. After this declaration, JBossAop will invoke any interceptor that associates with this POJO. TreeCacheAop will dynamically add an <tt class="literal">org.jboss.cache.aop.CacheInterceptor</tt> to this POJO to perform object mapping and relationship management.</p><p>Note that to add your POJO, you should declare all the fields will be "advised" as in the example.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e427"></a><a name="d0e428"></a><b>Q:</b></td><td align="left" valign="top"><p>Do I need to declare all my objects "prepare" in <tt class="literal">jboss-aop.xml</tt>?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Not necessarily. If there is some objects that you don't need 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 <tt class="literal">Serializable</tt> interface though.</p></td></tr></tbody></table></div></div></body></html>
  \ No newline at end of file
  +tx.commit();</pre></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e245"></a><a name="d0e246"></a><b>Q:</b></td><td align="left" valign="top"><p>How do I control the cache locking level?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>JBossCache let you control the cache locking level through the transaction isolation level. This is configured through the attribute <tt class="literal">IsolationLevel</tt>. Currently, JBossCache employs pessimistic locking internally. And the transaction isolation level from the pessimist locking corresponds to JDBC isolation levels, namely, <tt class="literal">NONE</tt>, <tt class="literal">READ_UNCOMMITTED</tt>, <tt class="literal">READ_COMMITTED</tt>, <tt class="literal">REPEATABLE_READ</tt>, and <tt class="literal">SERIALIZABLE</tt>. For details, please refer to the user manual.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e270"></a><a name="d0e271"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache support eviction policy?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. JBossCache currently implements a LRU eviction policy for both TreeCache (<tt class="literal">org.jboss.cache.eviction.LRUPolicy</tt>) and TreeCacheAop (<tt class="literal">org.jboss.cache.eviction.AopLRUPolicy</tt>). Users can also plug in their own eviction policy algorithms. See user manual for details.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e283"></a><a name="d0e284"></a><b>Q:</b></td><td align="left" valign="top"><p>Why can't I use <tt class="literal">org.jboss.cache.eviction.LRUPolicy</tt> for TreeCacheAop as well?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>For TreeCacheAop, you will need to use <tt class="literal">org.jboss.cache.eviction.AopLRUPolicy</tt>) because AOP has its eviction algorithm, although is LRU but has totally different notion of an "object", for example.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e296"></a><a name="d0e297"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache's implemented LRU eviction policy operates in replication mode?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes and no. :-)</p><p>The LRU policy only operates in local mode. That is, nodes that are only evicted locally. This may cause the cache contents not to be synchronized temporarily. But when a user tries to obtain a cache content of an evicted node and finds out that is null (e.g., get returns null), it should get it from 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.</p><p>However, you still can run eviction policy with cache mode set to either <tt class="literal">REPL_SYNC</tt> or <tt class="literal">REPL_ASYNC</tt>. Depends on your use case, you can set multiple cache instances to have their own eviction policy (of which is operated locally) or just have selected instance with eviction policy activated.</p><p>Also note that, when the cache persistence layer is implemented in the next release, an locally evicted node can also be persisted to the backend store.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e315"></a><a name="d0e316"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache support <tt class="literal">Region</tt>?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. JBossCache has the notion of region where a user can configure the eviction policy parameters (e.g., <tt class="literal">maxNodes</tt> or <tt class="literal">timeToIdelSeconds</tt> )</p><p>A region in JBossCache denotes a portion of tree hierarchy, e.g., a fully qualified name (<tt class="literal">FQN</tt>). For example, a user can define <tt class="literal">/org/jboss</tt> and <tt class="literal">/org/foocom</tt> as two separate regions.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e342"></a><a name="d0e343"></a><b>Q:</b></td><td align="left" valign="top"><p>Can I monitor and manage the JBossCache?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>If you are running JBossCache as a MBean service inside JBoss, you can monitor and manage through the jmx console. We plan to add more attributes such as cache hit/miss numbers in the future release.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e349"></a><a name="d0e350"></a><b>Q:</b></td><td align="left" valign="top"><p>Does JBossCache support partitioning?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Not right now. JBossCache 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.</p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><a name="d0e356"></a><h3 class="title"><a name="d0e356"></a>3. TreeCacheAop</h3></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e359"></a><a name="d0e360"></a><b>Q:</b></td><td align="left" valign="top"><p>What is TreeCacheAop?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>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.</p><p>From a user perspective, once the object 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 TreeCacheAop (by calling putObject, for example), then any get/set method will be intercepted by TreeCacheAop to provide the data from the cache.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e368"></a><a name="d0e369"></a><b>Q:</b></td><td align="left" valign="top"><p>Does TreeCacheAop have all the functional capabilities of TreeCache?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. TreeCacheAop extends TreeCache so it has all the same features TreeCache such as cache mode, transaction isolation level, and eviction policy.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e375"></a><a name="d0e376"></a><b>Q:</b></td><td align="left" valign="top"><p>What is the difference between TreeCache and TreeCacheAop?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Think of TreeCacheAop as a TreeCache on steroid. :-) Seriously, both are cache store. However, while TreeCache only provides pure object reference storage (e.g., <tt class="literal">put(FQN fqn, Objecy key, Object value)</tt>), 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.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e385"></a><a name="d0e386"></a><b>Q:</b></td><td align="left" valign="top"><p>Can I pre-compile the aop classes such that I don't need to use the system classloader and jboss-aop configuration xml?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Yes. The latest versions of JBossCache has a per-compiler option called <tt class="literal">aopc</tt>. You can use this option to pre-compile your "advised" POJO. Once the classes have been byte code generated, it can be treated as regular class files, i.e., you will not need to include any <tt class="literal">jboss-aop.xml</tt> that specifies the advisable POJO and to specify the JBossAop system class loader.</p><p>For an example of how to use <tt class="literal">aopc</tt>, please see the <tt class="literal">build.xml</tt> in the standalone package.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e406"></a><a name="d0e407"></a><b>Q:</b></td><td align="left" valign="top"><p>What's in the <tt class="literal">jboss-aop.xml</tt> configuration?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>In <tt class="literal">jboss-aop.xml</tt>, you declare your POJO (e.g., <tt class="literal">Person</tt> to be "prepared", a JBOssAop term to denote that the object will be "advised" by the system. After this declaration, JBossAop will invoke any interceptor that associates with this POJO. TreeCacheAop will dynamically add an <tt class="literal">org.jboss.cache.aop.CacheInterceptor</tt> to this POJO to perform object mapping and relationship management.</p><p>Note that to add your POJO, you should declare all the fields will be "advised" as in the example.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e427"></a><a name="d0e428"></a><b>Q:</b></td><td align="left" valign="top"><p>Do I need to declare all my objects "prepare" in <tt class="literal">jboss-aop.xml</tt>?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>Not necessarily. If there is some objects that you don't need 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 <tt class="literal">Serializable</tt> interface though.</p></td></tr><tr class="question"><td align="left" valign="top"><a name="d0e440"></a><a name="d0e441"></a><b>Q:</b></td><td align="left" valign="top"><p>How do I use <tt class="literal">List</tt>, <tt class="literal">Set</tt>, and <tt class="literal">Map</tt> dynamic proxy?</p></td></tr><tr class="answer"><td align="left" valign="top"><b>A:</b></td><td align="left" valign="top"><p>TreeCacheAop supports classes extends from <tt class="literal">List</tt>, <tt class="literal">Set</tt>, and <tt class="literal">Map</tt> without users to declare it "advised". It is done via a dynamic proxy. Here is a code snippet to use an <tt class="literal">ArrayList</tt> class.</p><pre class="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.
  +
  +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");</pre></td></tr></tbody></table></div></div></body></html>
  \ No newline at end of file