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).
anonymous wrote :
| TreeCache Passivation/ Overflow
| ===============================
|
|
|
| Author: Hany Mesha (hm...@no...)
| 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
|
|
| Goal:
| -----
|
| 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.
|
| Configuration:
| --------------
| - CachePassivation: flag to be set by user to enable/ disable cache passivation
| EXAMPLE:
|
| org.jboss.cache.loader.FileCacheLoader
| location=c:\\tmp\\node1
| false
| /
| false
| true
| <!-- Cache Passivation for Tree Cache -->
| true
|
| Use Case:
| ---------
| See Related Issues section at the bottom of this document.
|
| Design:
| -------
|
| Passivation
| -----------
| 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
| loader.store(evictedNode);
| }
| else {
| ...
| }
| }
|
|
|
| Question:
| ---------
| 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?
|
| Activation:
| -----------
| Question
| --------
| 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.
|
| Question:
| ---------
| 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
| NOT YET FINISHED.
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885128#3885128
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885128
|
