<chapter id="configuration">


      <title>Configuration</title>

      <para>Since PojoCache inherits from TreeCache, the xml configuration
         file attributes are almost identical to that of the latter one. Attributes such
         as replication mode, transaction manager, eviction policy, cache loader,
         and JGroups stack, for example, are still the same. There are two
         differences, however, when using the xml file--- configuring as a MBean
         service and eviction policy.</para>

      <sect1>
         <title>PojoCache MBean service</title>

         <para>PojoCache can also be deployed as a MBean service under JBoss
            Application Server. However, you will need to use the correct class to
            instantiate. For example, this is the code snippet for the MBean
            attribute in the xml file:
            <programlisting>&lt;mbean code="org.jboss.cache.aop.PojoCache" name="jboss.cache:service=PojoCache"&gt;</programlisting>
            You can modify the object service name to your liking, of course.
         </para>
      </sect1>

      <sect1>
         <title>PojoCache eviction policy</title>

         <para>PojoCache also provides an eviction policy,
            <literal>org.jboss.cache.aop.eviction.AopLRUPolicy</literal>
            , that is a
            subclass of
            <literal>org.jboss.cache.eviction.LRUPolicy</literal>
            (with
            the same configuration parameters). The reason we need a distinctive
            implementation is because eviction in PojoCache is quite different
            from the regular TreeCache. In the plain cache world, a unit is a FQN
            node, while in the aop world, the concept of a unit is an object (which
            can have multiple nodes and children nodes!).
         </para>

         <para>In addition, once a user obtains a POJO reference, everything is
            supposed to be transparent, e.g., cache retrieval and update operations.
            But if an object is evicted, that means there is no
            <literal>CacheInterceptor</literal>
            for the POJO, and the contents are
            not intercepted by the cache. Instead, every operation access will be
            channeled to the in-memory reference. So all operations will succeed but
            then a user has no way of knowing that it is merely updating the
            in-memory reference!
         </para>

         <para>To remedy this problem, we currently requires that eviction policy is used in combination of a cache loader
            to persist the data. It can either be fully persistency or passivation (e.g., only persist when it is evicted).
            In this way, when the node is not available it will be retrieved from the persistent store. The downside is that
            the POJO won't be transient, e.g., it is persistent all time unless a specific user-based
            <literal>removeObject</literal> is called.
         </para>
      </sect1>


</chapter>