This content has been marked as final.
Show 2 replies
-
1. Re: Cache Passivation/ Overflow
belaban Jul 16, 2005 4:22 AM (in response to hmesha)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
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:
<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.
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. -
2. Re: Cache Passivation/ Overflow
ben.wang Jul 17, 2005 9:50 PM (in response to hmesha)Hany,
I have added my comments and updated the doc in cvs as well. Look for BEN.
Thanks,
-Ben