[JBoss JIRA] Created: (JBCACHE-880) Add expiration policy for nodes based on a node's expiration key
by Elias Ross (JIRA)
Add expiration policy for nodes based on a node's expiration key
----------------------------------------------------------------
Key: JBCACHE-880
URL: http://jira.jboss.com/jira/browse/JBCACHE-880
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
It is useful to specify an expiration time (TTL) for cache values individually. For example, in caching web page contents, the data should be retained based on the HTTP header "Expires". Or, for caching session data, it should be kept based on the user's preference, e.g. Yahoo! Mail allows the authentication credentials to be cached from 1-24 hours.
Example usage:
TreeCache cache;
Fqn fqn1 = new Fqn("node1");
Fqn fqn2 = new Fqn("node2");
cache.put(fqn1, "expiration", new Long( ... ));
cache.put(fqn1, "data", ... );
cache.put(fqn2, "expiration", new Long( ... ));
cache.put(fqn2, "data", ... );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBCACHE-834) Combine eviction RegionManager with generic RegionManager
by Manik Surtani (JIRA)
Combine eviction RegionManager with generic RegionManager
---------------------------------------------------------
Key: JBCACHE-834
URL: http://jira.jboss.com/jira/browse/JBCACHE-834
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Manik Surtani
Assigned To: Manik Surtani
Fix For: 2.0.0.GA
This has already been done for the marshalling Regions and RegionManagers - do the same with eviction Regions and RegionManagers.
Also,
Another thing we need is equiv of the
o.j.c.eviction.RegionManager.markNodeCurrentlyInUse()/
unmarkNodeCurrentl yInUse() calls exposed in o.j.c.Region.
They are used by the LRUPolicy (and potentially others that implement
the feature) so the policy will ignore a node the app has marked "in
use".
Illustration of use by EJB3 SFSB:
1) User accesses bean.
2) StatefulTreeCache fetches bean from cache using get(). If no
transactional context at this point, RL from the get is released as soon
as method returns.
3) StatefulTreeCache call markNodeCurrentlyInUse
4) User invokes method on bean that takes a long time.
5) Eviction thread kicks in. Would ordinarily evict the bean since the
get() in #2 happened a while ago. But the node-in-use event tells it
not to.
6) User invocation finishes, bean is released.
7) StatefulTreeCache calls unmarkNodeCurrentlyInUse.
8) Bean can now be evicted on later eviction thread run.
I'd thought the changes were discussing of moving the lock interceptor
up in the order might help, but they don't -- as mentioned in step 2,
the bean can be "in use" long after any lock is held on its cache node.
Semantics we'd need are pretty much what we have now in 1.4 -- when
method is invoked, if the region is configured for eviction, create an
EvictedEventNode object and put it in the event queue. Only difference
is RegionManager doesn't get involved to find the region -- the app
should do that itself via the Cache API.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months