JBoss.org Community Documentation
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).