[
https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-2916:
------------------------------------
Indeed [~pferraro], that was the solution I was going to suggest as well.
OTOH Radim is also right, there are two problems:
1. Expiration doesn't actually remove the entry, so it's possible for an entry to
re-appear in the cache if the timer is not monotonic. In particular, it's very likely
that the key does not expire at the exact same time on all the nodes, so a node that
doesn't have the group locally may get different results depending on which owner
answers first (since we send the remote get to all the owners). True, this won't
happen very often, but it can certainly happen during state transfer.
2. Reading doesn't acquire any locks. So just because you read the a key in a
transaction, it doesn't mean that the key can't expire while the transaction is
active. Note that expiration doesn't acquire any locks either, but that might need to
change in order to implement expiration listeners.
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 (or at least some pre-determined "primary" key), 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