[
https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin....
]
Paul Ferraro updated ISPN-2916:
-------------------------------
Description:
Now that WildFly represents a web session as a group of cache entries (instead of a single
entry containing an atomic map), there are a few hurdles preventing us from leveraging
infinispan-managed expiration.
One of which is the fact that expiration of cache entries within a group *must* be atomic.
It would be very bad if a request arrives for a session whose entries are in the process
of being expired. The expiration thread should obtain a lock on *all* the keys for a
group, so that late session access doesn't result in session attributes mysteriously
disappearing (because they were independently expired). This can also cause integrity
constraint violations if cache entries reference other entries in the group. e.g.
currently the "primary" cache entry for a session (keyed by session id),
contains a set of attribute names. These names correspond to other cache entries that
contain the value of a given attribute for that session.
was:While exploring the possibility of replacing single cache entries containing atomic
maps with multiple cache entries using the grouping api, it occurred to me that to do this
would require auto-eviction/expiration to be atomic for a group. Otherwise, we would run
the risk of integrity constraint violations when cache entries are automatically expired
or evicted.
Group-based expiration
----------------------
Key: ISPN-2916
URL:
https://issues.jboss.org/browse/ISPN-2916
Project: Infinispan
Issue Type: Feature Request
Components: Core
Affects Versions: 5.2.5.Final
Reporter: Paul Ferraro
Assignee: Mircea Markus
Now that WildFly represents a web session as a group of cache entries (instead of a
single entry containing an atomic map), there are a few hurdles preventing us from
leveraging infinispan-managed expiration.
One of which is the fact that expiration of cache entries within a group *must* be
atomic. It would be very bad if a request arrives for a session whose entries are in the
process of being expired. The expiration thread should obtain a lock on *all* the keys
for a group, so that late session access doesn't result in session attributes
mysteriously disappearing (because they were independently expired). This can also cause
integrity constraint violations if cache entries reference other entries in the group.
e.g. currently the "primary" cache entry for a session (keyed by session id),
contains a set of attribute names. These names correspond to other cache entries that
contain the value of a given attribute for that session.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira