2 Replies Latest reply on Jul 17, 2005 9:50 PM by ben.wang

    Cache Passivation/ Overflow

    Hany Mesha Novice

      Hello all,

      Let me first introduce myself, My name is Hany Morris Mesha. I work for Novell web applications R&D. I've recently joined the effort on JBoss Cache development.

      I started the design for JBCACHE-66 and had discussions with Bela and Ben about the approach to be take in the design. Based on those discussions I have created a design document and checked it in under JBossCache/docs/design/TeeCachePassivation.txt. I have 3 questions listed in the document that I'd appreciate your input on as well as anything else you might see in there.

      Please review the design and let me know your opinion.


      - Hany

        • 1. Re: Cache Passivation/ Overflow
          Bela Ban Master

          Okay, I modified the document slightly. Search for "BELA" in the text. I'll post the document below (it is also in the CVS, under JBossCache/docs/design).

          TreeCache Passivation/ Overflow

          Author: Hany Mesha (hmesha@novell.com)
          Revision: $Id: TreeCachePassivation.txt,v 1.3 2005/07/16 08:20:06 bela Exp $:

          JIRA issue: http://jira.jboss.com/jira/browse/JBCACHE-66


          When a cache is full and a new object needs to be loaded into the cache, an
          existing object must be removed from the cache to make room for the new object.
          However, re-creating and re-loading a large objects in in-memory cache is
          expensive. Therefore, Passivation/ Activation is a mechanism to avoid such
          performance costly operations.

          When an object is called back by the Eviction Policy Provider in the
          TreeCache for eviction, The TreeCache will determine whether to passivate
          the object or simply remove it. The decision will be based on the value of
          CacheLoaderEnablePassivation flag in the cache loader configuration group
          (true/ false) of the cache configuration file.

          Passivation is the process of removing an object from in-memory cache and
          persisting it to a secondary data store (i.e. file system, database) on eviction.

          Activation is the process of restoring an object from the data store into the
          in-memory cache when it's needed to be used.

          In both cases, the configured CacheLoader will be used to read from the data store
          or write to the data store.

          - CachePassivation: flag to be set by user to enable/ disable cache passivation

          <attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute>
          <attribute name="CacheLoaderConfig">location=c:\\tmp\\node1</attribute>
          <attribute name="CacheLoaderShared">false</attribute>
          <attribute name="CacheLoaderPreload">/</attribute>
          <attribute name="CacheLoaderFetchTransientState">false</attribute>
          <attribute name="CacheLoaderFetchPersistentState">true</attribute>
          <!-- Cache Passivation for Tree Cache -->
          <attribute name="CacheLoaderEnablePassivation">true</attribute>

          Use Case:
          See Related Issues section at the bottom of this document.


          1. implements Interceptor:
          Passivation will be implemented using interceptors; see Refactoring.txt for details on interceptors.

          - TreeCache.createInterceptorChain() will assemble the interceptor stack starting with the passivation
          interceptor at the bottom of the stack

          - passivation should be applied for the whole node and its children therefore the passivation interceptor
          will only act on node node evict() on the way in.

          2. passivate node on eviction:
          When the eviction policy in effect calls its evict() (calls TreeCache.evict(fqn) or TreeCacheAop.evict(fqn))
          to evict a node from the underlying cache instance, the passivation interceptor will intercept the call and
          store the node and its children in the cache loader store.

          Pseudo code in PassivationInterceptor:

          public Object invoke(MethodCall m) throws Throwable {
          Method meth=m.getMethod();
          Object[] args=m.getArgs();

          if(meth.equals(TreeCache.evictNodeMethodLocal) {
          Fqn evictedNode=(Fqn)args[0];
          // the evict() method is called; store the evicted node in the cache loader
          else {

          Should we brute force remove of the node from in-memory cache?
          BELA: no, this will be done by the eviction policy. Note that non-leaf nodes
          are not removed from memory, but just cleared of their data

          Also, should we make sure that the node is not added to the removal queue otherwise the cache store
          interceptor will be triggered to remove it from the cache loader store and will be impossible to activate
          the node again?

          On incoming get method call, don't do anything and let the call climb up the cache loader interceptor in the
          stack or should we handle a get in the cache passivation interceptor to manually get the node from the cache
          loader, store it in the in-memory cache, then remove it from the cache loader? If we do so how can we distinguish
          between persisted and passivated node?

          BELA: The ActivationInterceptor should *replace* the CacheLoaderInterceptor (similar to the
          PassivationInterceptor which replaces the CacheStoreInterceptor). The ActivationInterceptor can simply
          extend the CacheLoaderInterceptor and, on GET, call super.GET(), which loades from the store, then remove
          the element from the store. Similarly, the PassivationInterceptor could extend CacheStoreInterceptor.

          BELA: passivation and activation *replace* regular cache loading, so we don't need to differentiate
          between persisted and passivated objects. You can have either persisted, or passivated, but not both, objects.

          4. Transaction:
          The cache passivation interceptor will be modeled after the cache store interceptor which is transaction aware.
          It will have an inner class SynchronizationHandler which implements transaction synchronization. It will build
          transaction modification (EVENT_EVICT) list and pass it to the cache loader on passivation. On activation, it's
          a get therefore, there's no transaction process involved.
          BELA: maybe we can inherit this from the respective superclasses

          Related Issues:

          - JBCLUSTER-15
          Affected packages in cluster: org.jboss.ha.httpsession.server
          Currenlty JBoss Clustering HTTP Session replication doesn't support passivation. http session is wraps in an
          entity bean to persist the session. ClusteredHTTPSessionService has an inner class, CleanupDaemon, that runs on
          a separate thread every 30 seconds to remove the timed out session's EJB object from the entity bean. That
          puts the entity bean back in the pool of available instances and the session information not accessiable anymore.

          To avoid the cost of recreating those EJB objects, ClusteredHTTPSessionService should use JBoss Cache
          passivation feature. When the session times out, instead of throwing it away.

          On the other hand, ClusteredHTTPSessionService is a standalone jmx service and doesn't use
          org.jboss.ha.framework.server to handle cluster communications.

          There're two ways to handle passivation:
          1. keep the existing jmx service and write custom class that will be modeled after the ejb3 sfsb passivation
          2. Replace the jmx service with HA framework, keep in mind though that passivation will only act on a node and
          the HA framework act on a key-value pair, need to be thought through.

          Should we use approach 1 or 2?

          - JBCLUSTER-40
          Affected packages in ejb3: org.jboss.ejb3.cache.tree, org.jboss.ejb3.stateful

          Currently ejb3 has its own activation/ passivation mechanism which uses JBoss Cache File cache loader to
          passivate and activate sfsb. Once JBoss Cache implements this feature, ejb3 should re-work its passivation
          policy to take advantage of the new feature as follow:
          1. Add to org.jboss.cache.TreeCache public EvictionPolicy getEvictionPolicy() and remove org.jboss.ejb3.cache.tree.PassivationTreeCache
          2. Change the implementation in org.jboss.cache.treeCache.StatefulTreeCache.
          3. Add to org.jboss.cache.eviction.BaseEviction public void createRegion(String name, int maxSize, long timeToLive)
          and public void removeRegion(String name) to act on the RegionManager. Then, remove org.jboss.ejb3.cache.tree.PassivationEvictionPolicy
          4. Change the implementation in org.jboss.cache.tree.StatefulEvictionPolicy.
          5. Remove org.jboss.ejb3.cache.tree.PassivationCacheLoader,
          6. Change the implementation in org.jboss.ejb3.cache.tree.StatefulCacheLoader
          7. Refactor the changes in org.jboss.ejb3.stateful where necessary
          8. turn the passivation flag to true in the cache service on the sfsb container startup???

          - JBCACHE-159

          • 2. Re: Cache Passivation/ Overflow


            I have added my comments and updated the doc in cvs as well. Look for BEN.