POJO Cache

The section lists some basic terminology that will be used throughout this guide.

JBoss Cache consists of two components, Core Cache, and POJO Cache. Core Cache provides efficient memory storage, transactions, replication, eviction, persistent storage, and many other "core" features you would expect from a distributed cache. The Core Cache API is tree based. Data is arranged on the tree using nodes that each offer a map of attributes. This map-like API is intuitive and easy to use for caching data, but just like the Java Collection API, it operates only off of simple and serializable types. Therefore, it has the following constraints:

Figure 2.1. Illustration of shared objects problem during replication

POJO Cache attempts to address these issues by building a layer on top of Core Cache which transparently maps normal Java object model operations to individual Node operations on the cache. This offers the following improvements:

In POJO Cache, these are the typical development and programming steps:

More details on these steps will be given in later chapters.

Since POJO Cache is a layer on-top of Core Cache, all features available in Core Cache are also available in POJO Cache. Furthermore, you can obtain an instance to the underlying Core Cache by calling PojoCache.getCache(). This is useful for resusing the same cache instance to store custom data, along with the POJO model.

Here are the current features and benefits of PojoCache:

To use POJO Cache, you obtain the instance from the PojoCacheFactory by supplying a config file that is used by the delegating Cache implementation. Once the PojoCache instance is obtained, you can call the cache life cycle method to start the cache. Below is a code snippet that creates and starts the cache:

String configFile = "replSync-service.xml";
boolean toStart = false;
PojoCache pcache = PojoCacheFactory.createCache(configFiel, toStart);
pcache.start(); // if toStart above is true, it will starts the cache automatically.
pcache.attach(id, pojo);
...
pcache.stop(); // stop the cache. This will take PojoCache out of the clustering group, if any, e.g.

POJO Cache is currently supported on JDK 5 (since release 2.0). It requires the following libraries (in addition to jboss-cache.jar and the required libraries for Core Cache) to start up:

As mentioned, the JBoss Aop framework is used to provide a configurable interceptor stack. In the current implementation, the main POJO Cache methods have their own independant stack. These are specified in META-INF/pojocache-aop.xml In most cases, this file should be left alone, although advanced users may wish to add their own interceptors. The Following is the default configuration:

   <!-- Check id range validity -->
   <interceptor name="CheckId" class="org.jboss.cache.pojo.interceptors.CheckIdInterceptor"
         scope="PER_INSTANCE"/>

   <!-- Track Tx undo operation -->
   <interceptor name="Undo" class="org.jboss.cache.pojo.interceptors.PojoTxUndoInterceptor"
         scope="PER_INSTANCE"/>

   <!-- Begining of interceptor chain -->
   <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
         scope="PER_INSTANCE"/>

   <!-- Check if we need a local tx for batch processing -->
   <interceptor name="Tx" class="org.jboss.cache.pojo.interceptors.PojoTxInterceptor"
         scope="PER_INSTANCE"/>

   <!--
      Mockup failed tx for testing. You will need to set PojoFailedTxMockupInterceptor.setRollback(true)
      to activate it.
   -->
   <interceptor name="MockupTx" class="org.jboss.cache.pojo.interceptors.PojoFailedTxMockupInterceptor"
         scope="PER_INSTANCE"/>

   <!-- Perform parent level node locking -->
   <interceptor name="TxLock" class="org.jboss.cache.pojo.interceptors.PojoTxLockInterceptor"
         scope="PER_INSTANCE"/>

   <!-- Interceptor to perform Pojo level rollback -->
   <interceptor name="TxUndo" class="org.jboss.cache.pojo.interceptors.PojoTxUndoSynchronizationInterceptor"
                scope="PER_INSTANCE"/>

   <!-- Interceptor to used to check recursive field interception. -->
   <interceptor name="Reentrant" class="org.jboss.cache.pojo.interceptors.MethodReentrancyStopperInterceptor"
                scope="PER_INSTANCE"/>

   <!-- Whether to allow non-serializable pojo. Default is false. -->
   <interceptor name="MarshallNonSerializable" class="org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor"
                scope="PER_INSTANCE">
         <attribute name="marshallNonSerializable">false</attribute>
                </interceptor>

   <stack name="Attach">
      <interceptor-ref name="Start"/>
      <interceptor-ref name="CheckId"/>
      <interceptor-ref name="Tx"/>
      <interceptor-ref name="TxLock"/>
      <interceptor-ref name="TxUndo"/>
   </stack>

   <stack name="Detach">
      <interceptor-ref name="Start"/>
      <interceptor-ref name="CheckId"/>
      <interceptor-ref name="Tx"/>
      <interceptor-ref name="TxLock"/>
      <interceptor-ref name="TxUndo"/>
   </stack>

   <stack name="Find">
      <interceptor-ref name="Start"/>
      <interceptor-ref name="CheckId"/>
   </stack>

The stack should be self-explanatory. For example, for the Attach stack, we currently have Start, CheckId, Tx, TxLock, and TxUndo interceptors. The stack always starts with a Start interceptor such that initialization can be done properly. CheckId is to ensure the validity of the Id (e.g., it didn't use any internal Id string). Finally, Tx, TxLock, and TxUndo are handling the the proper transaction locking and rollback behavior (if needed).

POJO Cache currently uses JBoss AOP to intercept field operations. If a class has been properly instrumented (by either using the @Replicable annotation, or if the object has already been advised by JBoss AOP), then a cache interceptor is added during an attach() call. Afterward, any field modification will invoke the corresponding CacheFieldInterceptor instance. Below is a schematic illustration of this process.

Only fields, and not methods are intercepted, since this is the most efficient and accurate way to gaurantee the same data is visible on all nodes in the cluster. Further, this allows for objects that do not conform to the JavaBean specficiation to be replicable. There are two important aspects of field interception:

The figure below illustrates both field read and write operations. Once an POJO is managed by POJO Cache (i.e., after an attach() method has been called), JBoss Aop will invoke the CacheFieldInterceptor every time a class operates on a field. The cache is always consulted, since it is in control of the mapped data (i.e. it gaurantess the state changes made by other nodes in the cluster are visible). Afterwords, the in-memmory copy is updated. This is mainly to allow transaction rollbacks to restore the previous state of the object.

Figure 3.2. POJO Cache field interception

As previously mentioned, unlike a traditional cache system, POJO Cache preserves object identity. This allows for any type of object relationship available in the Java language to be transparently handled.

During the mapping process, all object references are checked to see if they are already stored in the cache. If already stored, instead of duplicating the data, a reference to the original object is written in the cache. All referenced objects are reference counted, so they will be removed once they are no longer referenced.

To look at one example, let's say that multiple Persons ("joe" and "mary") objects can own the same Address (e.g., a household). The following diagram is a graphical representation of the pysical cache data. As can be seen, the "San Jose" address is only stored once.

Figure 3.3. Schematic illustration of object relationship mapping

In the following code snippet, we show programmatically the object sharing example.

import org.jboss.cache.pojo.PojoCache;
import org.jboss.cache.pojo.PojoCacheFactory;
import org.jboss.test.cache.test.standAloneAop.Person;
import org.jboss.test.cache.test.standAloneAop.Address;

String configFile = "META-INF/replSync-service.xml";
PojoCache cache = PojoCacheFactory.createCache(configFile); // This will start PojoCache automatically

Person joe = new Person(); // instantiate a Person object named joe
joe.setName("Joe Black");
joe.setAge(41);

Person mary = new Person(); // instantiate a Person object named mary
mary.setName("Mary White");
mary.setAge(30);

Address addr = new Address(); // instantiate a Address object named addr
addr.setCity("Sunnyvale");
addr.setStreet("123 Albert Ave");
addr.setZip(94086);

joe.setAddress(addr); // set the address reference
mary.setAddress(addr); // set the address reference

cache.attach("pojo/joe", joe); // add aop sanctioned object (and sub-objects) into cache.
cache.attach("pojo/mary", mary); // add aop sanctioned object (and sub-objects) into cache.

Address joeAddr = joe.getAddress();
Address maryAddr = mary.getAddress(); // joeAddr and maryAddr should be the same instance

cache.detach("pojo/joe");
maryAddr = mary.getAddress(); // Should still have the address.

If joe is removed from the cache, mary should still have reference the same Address object in the cache store.

To further illustrate this relationship management, let's examine the Java code under a replicated environment. Imagine two separate cache instances in the cluster now (cache1 and cache2). On the first cache instance, both joe and mary are attached as above. Then, the application fails over to cache2. Here is the code snippet for cache2 (assume the objects were already attached):

/**
 * Code snippet on cache2 during fail-over
 */
import org.jboss.cache.PropertyConfigurator;
import org.jboss.cache.pojo.PojoCache;
import org.jboss.test.cache.test.standAloneAop.Person;
import org.jboss.test.cache.test.standAloneAop.Address;

String configFile = "META-INF/replSync-service.xml";
PojoCache cache2 = PojoCacheFactory.createCache(configFile); // This will start PojoCache automatically

Person joe = cache2.find("pojo/joe"); // retrieve the POJO reference.
Person mary = cache2.find("pojo/mary"); // retrieve the POJO reference.

Address joeAddr = joe.getAddress();
Address maryAddr = mary.getAddress(); // joeAddr and maryAddr should be the same instance!!!

maryAddr = mary.getAddress().setZip(95123);
int zip = joeAddr.getAddress().getZip(); // Should be 95123 as well instead of 94086!

POJO Cache preserves the inheritance hierarchy of all attached objects. For example, if a Student extends Person with an additional field year, then once Student is put into the cache, all the class attributes of Person are mapped to the cache as well.

Following is a code snippet that illustrates how the inheritance behavior of a POJO is maintained. Again, no special configuration is needed.

import org.jboss.test.cache.test.standAloneAop.Student;

Student joe = new Student(); // Student extends Person class
joe.setName("Joe Black"); // This is base class attributes
joe.setAge(22); // This is also base class attributes
joe.setYear("Senior"); // This is Student class attribute

cache.attach("pojo/student/joe", joe);

//...

joe = (Student)cache.attach("pojo/student/joe");
Person person = (Person)joe; // it will be correct here
joe.setYear("Junior"); // will be intercepted by the cache
joe.setName("Joe Black II"); // also intercepted by the cache

The previous sections describe the logical object mapping model. In this section, we will explain the physical mapping model, that is, how do we map the POJO into Core Cache for transactional state replication. However, it should be noted that the physical structure of the cache is purely an internal implementation detail, it should not be treated as an API as it may change in future releases. This information is provided solely to aid in better understanding the mapping process in POJO Cache.

When an object is first attached in POJO Cache, the Core Cache node representation is created in a special internal area. The Id fqn that is passed to attach() is used to create an empty node that references the internal node. Future references to the same object will point to the same internal node location, and that node will remain until all such references have been removed (detached).

The example below demonstrates the mapping of the Person object under id "pojo/joe" and "pojo/mary" as metioned in previous sections. It is created from a two node replication group where one node is a Beanshell window and the other node is a Swing Gui window (shown here). For clarity, multiple snapshots were taken to highlight the mapping process.

The first figure illustrates the first step of the mapping approach. From the bottom of the figure, it can be seen that the PojoReference field under pojo/joe is pointing to an internal location, /__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49n5o-2. That is, under the user-specified Id string, we store only an indirect reference to the internal area. Please note that Mary has a similar reference.

Figure 3.4. Object cache mapping for Joe

Figure 3.5. Object cache mapping for Mary

Then by clicking on the referenced internal node (from the following figure), it can seen that the primitive fields for Joe are stored there. E.g., Age is 41 and Name is Joe Black. And similarly for Mary as well.

Figure 3.6. Object cache mapping for internal node Joe

Figure 3.7. Object cache mapping for internal node Mary

Under the /__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49n5o-2, it can be seen that there is an Address node. Clicking on the Address node shows that it references another internal location: /__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49ngs-3 as shown in the following figure. Then by the same token, the Address node under /__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49na0-4 points to the same address reference. That is, both Joe and Mary share the same Address reference.

Figure 3.8. Object cache mapping: Joe's internal address

Figure 3.9. Object cache mapping: Mary's internal address

Finally, the /__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49ngs-3 node contains the various various primitive fields of Address, e.g., Street, Zip, and City. This is illustrated in the following figure.

Figure 3.10. Object cache mapping: Address fields

Due to current Java limitations, Collection classes that implement Set, List, and Map are substituted with a Java proxy. That is, whenever POJO Cache encounters any Collection instance, it will:

The drawback to this approach is that the calling application must re-get any collection references that were attached. Otherwise, the cache will not be aware of future changes. If the collection is referenced from another object, then the calling app can obtain the proxy by using the publishing mechanism provided by the object (e.g. Person.getHobbies()). If, however, the collection is directly attached to the cache, then a subsequent find() call will need to be made to retrieve the proxy.

The following code snippet illustrates obtaining a direct Collection proxy reference:

List list = new ArrayList();
list.add("ONE");
list.add("TWO");

cache.attach("pojo/list", list);
list.add("THREE"); // This won't be intercepted by the cache!

List proxyList = cache.find("pojo/list"; // Note that list is a proxy reference
proxyList.add("FOUR"); // This will be intercepted by the cache

This snippet illustrates obtaining the proxy reference from a refering object:

Person joe = new Person();
joe.setName("Joe Black"); // This is base class attributes
List lang = new ArrayList();
lang.add("English");
lang.add("Mandarin");
joe.setLanguages(lang);
// This will map the languages List automatically and swap it out with the proxy reference.
cache.attach("pojo/student/joe", joe);
lang = joe.getLanguages(); // Note that lang is now a proxy reference
lang.add("French"); // This will be intercepted by the cache

Finally, when a Collection is removed from the cache (e.g., via detach), you still can use the proxy reference. POJO Cache will just redirect the call back to the in-memory copy. See below:

List list = new ArrayList();
list.add("ONE");
list.add("TWO");

cache.attach("pojo/list", list);
List proxyList = cache.find("pojo/list"); // Note that list is a proxy reference
proxyList.add("THREE"); // This will be intercepted by the cache

cache.detach("pojo/list"); // detach from the cache
proxyList.add("FOUR"); // proxyList has 4 elements still.

PojoCacheFactory provides a couple of static methods to instantiate and obtain a PojoCache instance.

   /**
    * Create a PojoCache instance. Note that this will start the cache life cycle automatically.
    * @param config A configuration string that represents the file name that is used to
    * configure the underlying Cache instance.
    * @return PojoCache
    */
   public static PojoCache createInstance(String config);

   /**
    * Create a PojoCache instance.
    * @param config A configuration string that represents the file name that is used to
    * configure the underlying Cache instance.
    * @param start If true, it will start the cache life cycle.
    * @return PojoCache
    */
   public static PojoCache createInstance(String config, boolean start);

   /**
    * Create a PojoCache instance.
    * @param config A configuration object that is used to configure the underlying Cache instance.
    * @param start If true, it will start the cache life cycle.
    * @return PojoCache
    */
   public static PojoCache createInstance(Configuration config, boolean start);

For example, to obtain a PojoCache instance and start the cache lifestyle automatically, we can do:

   String configFile = "META-INF/replSync-service.xml";
   PojoCache cache = PojoCacheFactory.createInstance(configFile);

PojoCache is the main interface for POJO Cache operations. Since most of the cache interaction is performed against the application domain model, there are only a few methods on this interface.

   /**
    * Attach a POJO into PojoCache. It will also recursively put any sub-POJO into
    * the cache system. A POJO can be the following and have the consequences when attached:
    *
    * It is PojoCacheable, that is, it has been annotated with
    * {@see org.jboss.cache.aop.annotation.PojoCacheable} annotation (or via XML), and has
    * been "instrumented" either compile- or load-time. The POJO will be mapped recursively to
    * the system and fine-grained replication will be performed.
    *
    * It is Serializable. The POJO will still be stored in the cache system. However, it is
    * treated as an "opaque" object per se. That is, the POJO will neither be intercepted
    * (for fine-grained operation) or object relationship will be maintained.
    *
    * Neither of above. In this case, a user can specify whether it wants this POJO to be
    * stored (e.g., replicated or persistent). If not, a PojoCacheException will be thrown.
    *
    * @param id   An id String to identify the object in the cache. To promote concurrency, we
    *             recommend the use of hierarchical String separating by a designated separator. Default
    *             is "/" but it can be set differently via a System property, jbosscache.separator
    *             in the future release. E.g., "ben", or "student/joe", etc.
    * @param pojo object to be inserted into the cache. If null, it will nullify the fqn node.
    * @return Existing POJO or null if there is none.
    * @throws PojoCacheException Throws if there is an error related to the cache operation.
    */
   Object attach(String id, Object pojo) throws PojoCacheException;

   /**
    * Remove POJO object from the cache.
    *
    * @param id Is string that associates with this node.
    * @return Original value object from this node.
    * @throws PojoCacheException Throws if there is an error related to the cache operation.
    */
   Object detach(String id) throws PojoCacheException;

   /**
    * Retrieve POJO from the cache system. Return null if object does not exist in the cache.
    * Note that this operation is fast if there is already a POJO instance attached to the cache.
    *
    * @param id that associates with this node.
    * @return Current content value. Null if does not exist.
    * @throws PojoCacheException Throws if there is an error related to the cache operation.
    */
   Object find(String id) throws PojoCacheException;

   /**
    * Query all managed POJO objects under the id recursively. Note that this will not return
    * the sub-object POJOs, e.g., if Person has a sub-object of Address, it
    * won't return Address pojo. Also note also that this operation is not thread-safe
    * now. In addition, it assumes that once a POJO is found with a id, no more POJO is stored
    * under the children of the id. That is, we don't mix the id with different POJOs.
    *
    * @param id The starting place to find all POJOs.
    * @return Map of all POJOs found with (id, POJO) pair. Return size of 0, if not found.
    * @throws PojoCacheException Throws if there is an error related to the cache operation.
    */
   Map findAll(String id) throws PojoCacheException;

To declare a POJO via XML configuration file, you will need a META-INF/jboss-aop.xml (or in the PojoCache case, it is the equivalent pojocache-service.xml file located under the class path or listed in the jboss.aop.path system property. JBoss AOP framework will read this file during startup to make necessary byte code manipulation for advice and introduction. Or you can pre-compile it using a pre-compiler called aopc such that you won't need the XML file during load time. JBoss Aop provides a so-called pointcut language where it consists of a regular expression set to specify the interception points (or jointpoint in aop parlance). The jointpoint can be constructor, method call, or field. You will need to declare any of your POJO to be "prepared" so that AOP framework knows to start intercepting either method, field, or constructor invocations using the dynamic Aop.

For PojoCache, we only allow all the fields (both read and write) to be intercepted. That is, we don't care for the method level interception since it is the state that we are interested in. So you should only need to change your POJO class name. For details of the pointcut language, please refer to JBoss Aop.

The standalone JBoss Cache distribution package provides an example declaration for the tutorial classes, namely, Person and Address . Detailed class declaration for Person and Address are provided in the Appendix section. But here is the snippet for pojocache-aop.xml :

<aop>
  <prepare expr="field(* $instanceof{@org.jboss.cache.pojo.annotation.Replicable}->*)" />
</aop>

            <aop>
              <prepare expr="field(* @org.jboss.cache.pojo.annotation.Replicable->*)" />
            </aop>
            

Detailed semantics of pojocache-aop.xml (or equivalently pojocache-aop.xml) can again be found in JBoss Aop. But above statements basically declare all field read and write operations in classes Address and Person will be "prepared" (or "aspectized"). Note that:

Annotation is a new feature in Java 5.0 that when declared can contain metadata at compile and run time. It is well suited for aop declaration since there will be no need for external metadata xml descriptor.

<aop>
  <prepare expr="field(* @org.jboss.cache.pojo.annotation.Replicable->*)" />
</aop>

@org.jboss.cache.pojo.annotation.Replicable
public class Person {...}

public class Gadget
{
   // resource won't be replicated
   @Transient Resource resource;
   // specialAddress is treated as a Serializable object but still has object relationship
   @Serializable SpecialAddress specialAddress;
   // other state variables
}

   Gadget gadget = new Gadget();
   Resource resource = new Resource();
   SepcialAddress specialAddress = new SpecialAddress();

   // setters
   gadget.setResource(resource);
   gadget.setSpecialAddress(specialAddress);

   cache1.putObject("/gadget", gadget); // put into PojoCache management

   Gadget g2 = (Gadget)cache2.getObject("/gadget"); // retrieve it from another cache instance
   g2.getResource(); // This is should be null because of @Transient tag so it is not replicated.

   SepcialAddress d2 = g2.getSpecialAddress();
   d2.setName("inet"); // This won't get replicated automatically because of @Serializable tag
   ge.setSpecialAddress(d2); // Now this will.

As already mentioned, a user can use the aop precompiler (aopc) to precompile the POJO classes such that, during runtime, there is no additional system class loader needed. The precompiler will read in pojocache-aop.xml and weave the POJO byte code at compile time. This is a convenient feature to make the aop less intrusive.

Below is an Ant snippet that defines the library needed for the various Ant targets that we are listing here. User can refer to the build.xml in the distribution for full details.

   <path id="aop.classpath"/>
       <fileset dir="${lib}"/>
          <include name="**/*.jar" //>
          <exclude name="**/jboss-cache.jar" //>
          <exclude name="**/j*unit.jar" //>
          <exclude name="**/bsh*.jar" //>
       </fileset/>
   </path/>

   <target name="one.test.pojo" depends="compile" description="run one junit test case.">
     <junit printsummary="yes" timeout="${junit.timeout}" fork="yes">
        <jvmarg value="-Djboss.aop.path=${output}/resources/pojocache-aop.xml"/>
        <jvmarg value="-javaagent:${lib}/jboss-aop-jdk50.jar"/>
        <classpath path="${output}/etc" />
        <sysproperty key="log4j.configuration" value="file:${output}/etc/log4j.xml" />
        <classpath refid="lib.classpath"/>
        <classpath refid="build.classpath"/>
        <formatter type="xml" usefile="true"/>
        <test name="${test}" todir="${reports}"/>
     </junit>
   </target>

6.3.2. Ant target for aopc

Below is the code snippet for the aopc Ant target. Running this target will do compile-time weaving of the POJO classes specified.

   <taskdef name="aopc" classname="org.jboss.aop.ant.AopC" classpathref="aop.classpath"/>
   <target name="aopc" depends="compile" description="Precompile aop class">
      <aopc compilerclasspathref="aop.classpath" verbose="true">
         <src path="${build}"/>
         <include name="org/jboss/cache/aop/test/**/*.class"/>
         <aoppath path="${output}/resources/pojocache-aop.xml"/>
         <classpath path="${build}"/>
         <classpath refid="lib.classpath"/>
      </aopc>
   </target>

Below is a snapshot of files that are generated when aopc is applied. Notice that couple extra classes have been generated because of aopc.

Figure 6.1. Classes generated after aopc

The example POJO classes used for are: Person, Student, and Address. Below are their definition (note that neither class implements Serializable ) along with the annotation.

@org.jboss.cache.pojo.annotation.Replicable
public class Person {
   String name=null;
   int age=0;
   Map hobbies=null;
   Address address=null;
   Set skills;
   List languages;

   public String getName() { return name; }
   public void setName(String name) { this.name=name; }

   public int getAge() { return age; }
   public void setAge(int age) { this.age = age; }

   public Map getHobbies() { return hobbies; }
   public void setHobbies(Map hobbies) { this.hobbies = hobbies; }

   public Address getAddress() { return address; }
   public void setAddress(Address address) { this.address = address; }

   public Set getSkills() { return skills; }
   public void setSkills(Set skills) { this.skills = skills; }

   public List getLanguages() { return languages; }
   public void setLanguages(List languages) { this.languages = languages; }
}

public class Student extends Person {
   String year=null;

   public String getYear() { return year; }
   public void setYear(String year) { this.year=year; }
}

   @org.jboss.cache.pojo.annotation.Replicable
   public class Address {
   String street=null;
   String city=null;
   int zip=0;

   public String getStreet() { return street; }
   public void setStreet(String street) { this.street=street; }
   ...
}

Below is a sample xml configuration for Cache that you can use for PojoCache creation.

         
<?xml version="1.0" encoding="UTF-8" ?>

<server>
   <mbean code="org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper" 
          name="jboss.cache:service=PojoCache">
      
      <depends>jboss:service=TransactionManager</depends>

      <!-- Configure the TransactionManager -->
      <attribute name="TransactionManagerLookupClass">
         org.jboss.cache.transaction.DummyTransactionManagerLookup
      </attribute>

      <!-- Isolation level : SERIALIZABLE
                             REPEATABLE_READ (default)
                             READ_COMMITTED
                             READ_UNCOMMITTED
                             NONE
      -->
      <attribute name="IsolationLevel">REPEATABLE_READ</attribute>

      <!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC -->
      <attribute name="CacheMode">REPL_SYNC</attribute>

      <!-- Name of cluster. Needs to be the same for all caches, 
           in order for them to find each other
      -->
      <attribute name="ClusterName">PojoCacheCluster</attribute>

   	  <!-- JGroups protocol stack properties. -->
      <attribute name="ClusterConfig">
         <config>
            <!-- UDP: if you have a multihomed machine, set the bind_addr 
                 attribute to the appropriate NIC IP address -->
            <!-- UDP: On Windows machines, because of the media sense feature
                 being broken with multicast (even after disabling media sense)
                 set the loopback attribute to true -->
            <UDP mcast_addr="228.1.2.3" mcast_port="48866"
                 ip_ttl="64" ip_mcast="true"
                 mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
                 ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
                 loopback="false"/>
            <PING timeout="2000" num_initial_members="3"/>
            <MERGE2 min_interval="10000" max_interval="20000"/>
            <FD shun="true"/>
            <FD_SOCK/>
            <VERIFY_SUSPECT timeout="1500"/>
            <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
                           max_xmit_size="8192"/>
            <UNICAST timeout="600,1200,2400",4800/>
            <pbcast.STABLE desired_avg_gossip="400000"/>
            <FC max_credits="2000000" min_threshold="0.10"/>
            <FRAG2 frag_size="8192"/>
            <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
                        shun="true" print_local_addr="true"/>
            <pbcast.STATE_TRANSFER/>
         </config>
      </attribute>

      <!-- Whether or not to fetch state on joining a cluster -->
      <attribute name="FetchInMemoryState">true</attribute>

      <!-- The max amount of time (in milliseconds) we wait until the
           initial state (ie. the contents of the cache) are retrieved from
           existing members in a clustered environment
      -->
      <attribute name="InitialStateRetrievalTimeout">15000</attribute>

      <!-- Number of milliseconds to wait until all responses for a
           synchronous call have been received.
      -->
      <attribute name="SyncReplTimeout">15000</attribute>

      <!--  Max number of milliseconds to wait for a lock acquisition -->
      <attribute name="LockAcquisitionTimeout">10000</attribute>
   
   </mbean>
</server>

      

Attached is a full listing for pojocache-aop.xml.

   <?xml version="1.0" encoding="UTF-8"?>
   <!--
       This is the PojoCache configuration file that specifies:
         1. Interceptor stack for API
         2. Annotation binding for POJO (via "prepare" element)

       Basically, this is a variant of jboss-aop.xml. Note that
       except for the customization of interceptor stack, you should
       not need to modify this file.

       To run PojoCache, you will need to define a system property:
       jboss.aop.path that contains the path to this file such that JBoss Aop
       can locate it.
   -->
   <aop>

      <!--
      This defines the PojoCache 2.0 interceptor stack. Unless necessary, don't modify the stack here!
      -->

      <!-- Check id range validity -->
      <interceptor name="CheckId" class="org.jboss.cache.pojo.interceptors.CheckIdInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Track Tx undo operation -->
      <interceptor name="Undo" class="org.jboss.cache.pojo.interceptors.PojoTxUndoInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Begining of interceptor chain -->
      <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Check if we need a local tx for batch processing -->
      <interceptor name="Tx" class="org.jboss.cache.pojo.interceptors.PojoTxInterceptor"
                   scope="PER_INSTANCE"/>

      <!--
         Mockup failed tx for testing. You will need to set PojoFailedTxMockupInterceptor.setRollback(true)
         to activate it.
       -->
      <interceptor name="MockupTx" class="org.jboss.cache.pojo.interceptors.PojoFailedTxMockupInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Perform parent level node locking -->
      <interceptor name="TxLock" class="org.jboss.cache.pojo.interceptors.PojoTxLockInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Interceptor to perform Pojo level rollback -->
      <interceptor name="TxUndo" class="org.jboss.cache.pojo.interceptors.PojoTxUndoSynchronizationInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Interceptor to used to check recursive field interception. -->
      <interceptor name="Reentrant" class="org.jboss.cache.pojo.interceptors.MethodReentrancyStopperInterceptor"
                   scope="PER_INSTANCE"/>

      <!-- Whether to allow non-serializable pojo. Default is false. -->
      <interceptor name="MarshallNonSerializable"
                   class="org.jboss.cache.pojo.interceptors.CheckNonSerializableInterceptor"
                   scope="PER_INSTANCE">
            <attribute name="marshallNonSerializable">false</attribute>
                   </interceptor>

      <!-- This defines the stack macro -->
      <stack name="Attach">
         <interceptor-ref name="Start"/>
         <interceptor-ref name="CheckId"/>
         <interceptor-ref name="MarshallNonSerializable"/>
         <interceptor-ref name="Tx"/>
         <!-- NOTE: You can comment this out during production although leaving it here is OK. -->
         <interceptor-ref name="MockupTx"/>
         <interceptor-ref name="TxLock"/>
         <interceptor-ref name="TxUndo"/>
      </stack>

      <stack name="Detach">
         <interceptor-ref name="Start"/>
         <interceptor-ref name="CheckId"/>
         <interceptor-ref name="Tx"/>
         <!-- NOTE: You can comment this out during production although leaving it here is OK. -->
         <interceptor-ref name="MockupTx"/>
         <interceptor-ref name="TxLock"/>
         <interceptor-ref name="TxUndo"/>
      </stack>

      <stack name="Find">
         <interceptor-ref name="Start"/>
         <interceptor-ref name="CheckId"/>
      </stack>

      <!--
         The following section should be READ-ONLY!! It defines the annotation binding to the stack.
      -->

      <!-- This binds the jointpoint to specific in-memory operations. Currently in PojoUtil. -->
      <bind pointcut="execution(*
         @org.jboss.cache.pojo.annotation.Reentrant->toString())">
         <interceptor-ref name="Reentrant"/>
      </bind>

      <bind pointcut="execution(*
         org.jboss.cache.pojo.PojoUtil->@org.jboss.cache.pojo.annotation.TxUndo(..))">
         <interceptor-ref name="Undo"/>
      </bind>

      <bind pointcut="execution(* org.jboss.cache.pojo.impl.PojoCacheImpl->@org.jboss.cache.pojo.annotation.Attach(..))">
         <stack-ref name="Attach"/>
      </bind>

      <bind pointcut="execution(* org.jboss.cache.pojo.impl.PojoCacheImpl->@org.jboss.cache.pojo.annotation.Detach(..))">
         <stack-ref name="Detach"/>
      </bind>

      <bind pointcut="execution(* org.jboss.cache.pojo.impl.PojoCacheImpl->@org.jboss.cache.pojo.annotation.Find(..))">
         <stack-ref name="Find"/>
      </bind>


      <!--
         Following is declaration for JDK50 annotation. You use the specific annotation on your
         POJO such that it can be instrumented. Idea is user will then need only to annotate like:
   @org.jboss.cache.pojo.annotation.Replicable
   in his POJO. There will be no need of jboss-aop.xml from user's side.
      -->

      <!-- If a POJO has PojoCachable annotation, it will be asepctized. -->
      <prepare expr="field(* $instanceof{@org.jboss.cache.pojo.annotation.Replicable}->*)" />

      <!-- Observer and Observable to monitor field modification -->
      <bind pointcut="
         set(* $instanceof{@org.jboss.cache.pojo.annotation.Replicable}->*)
         ">
            <interceptor class="org.jboss.cache.pojo.observable.SubjectInterceptor"/>
      </bind>

      <introduction class="$instanceof{@org.jboss.cache.pojo.annotation.Replicable}">
         <mixin>
            <interfaces>org.jboss.cache.pojo.observable.Subject</interfaces>
            <class>org.jboss.cache.pojo.observable.SubjectImpl</class>
            <construction>new org.jboss.cache.pojo.observable.SubjectImpl(this)</construction>
         </mixin>
      </introduction>
   </aop>