When a user obtains a PojoCache instance from the PojoCacheFactory, it requires user pass in a configuration xml file. PojoCache will simply pass this xml to the underlying Cache implementation. As a result, any state replication aspects can be configured in this file, along with cache passivation. For details on the configuration xml, you can check out the core Cache documentation.

A user can also configure the underlying Cache to activate the passivation. Passivation is feature needed to keep the VM memory compact. In JBoss Cache, it is done via combination of eviction policy and cache loader. That is, when a node is evicted from Cache, it will store into the cache loader. When the node is requested again, it will be loaded from the store and stored into memory.

There is a restriction, however. Since we use the "flat space" physical POJO mapping, there are two places that has POJO information. One is under the regular String ID that the user specifies, and the other is located under /__JBossInteranl__. Therefore, to be consistent, when you specify the eviction region, you can only specify one global region (i.e., /_default_ region). This way, when the nodes associated with the POJO is passivated, they will do so across the whole region. Below is a snippet from a cache configuration xml illustrating how the eviction policy along with cache loader can be configured. Please note that this is simply an aspect of the underlying Cache. That is, PojoCache layer is agnostic to this behavior.

<attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
<attribute name="EvictionPolicyConfig">
   <config>
      <attribute name="wakeUpIntervalSeconds">5</attribute>
      <!-- Cache wide default -->
      <region name="/_default_">
          <attribute name="maxNodes">5000</attribute>
          <attribute name="timeToLiveSeconds">3</attribute>
      </region>
   </config>
</attribute>

<attribute name="CacheLoaderConfiguration">
   <config>
      <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
      <passivation>true</passivation>
      <preload>/</preload>
      <shared>false</shared>

      <!-- we can now have multiple cache loaders, which get chained -->
      <cacheloader>
         <class>org.jboss.cache.loader.FileCacheLoader</class>
         <!-- whether the cache loader writes are asynchronous -->
         <async>false</async>
         <!-- only one cache loader in the chain may set fetchPersistentState to true.
              An exception is thrown if more than one cache loader sets this to true. -->
         <fetchPersistentState>true</fetchPersistentState>
         <!-- determines whether this cache loader ignores writes - defaults to false. -->
         <ignoreModifications>false</ignoreModifications>
      </cacheloader>
   </config>
</attribute>

Another way to support multiple regions in eviction is to use Marshalling. When the Cache use marshalling, it has the side effect of placing all internal data under that specific region. As a result, the whole region will be passivated and activated at the same time.

PojoCache supplies a pojocache-aop.xml that is required to be set via a system property: jboss.aop.path during compile- or load-time, or placed in the user's classpath. The file now consists of interceptor stack specification and annotations for POJO instrumentation. It is listed fully in the Appendix section. Note that the file should be read mostly. So no need to modify it now unless you are customizing the interceptor chain, e.g.

TODO... This section needs to be filled in when the new JMX aspect is introduced.