JBoss.org Community Documentation

- Prev
- Next

## 3.1. POJO Cache interceptor stack

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).

- PrevChapter 3. Architecture
- Top of page
- Front page
- Next3.2. Field interception