[infinispan-issues] [JBoss JIRA] (ISPN-2916) Group-based expiration

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12956685#comment-12956685 ] 

Radim Vansa commented on ISPN-2916:
-----------------------------------

As expiration is driven based on wall-clock time, you'd have to store all the keys on one node (this is doable through key affinity service). Regrettably, current implementation of DefaultTimeService uses System.currentTimeMillis() which is not monotonic -> when one entry is reported as expired, you can't be sure that another entry with the same expiration will be reported as expired as well.

The option using expiration listeners (ISPN-694) on primary key has another problem - even if you executed all the removes within transaction, transaction writes are *not* atomic with respect to reads (if {{k1=v1}} and {{k2=v2}} and you do {{T1: remove(k1), remove(k2)}} and {{T2: read(k1), read(k2)}} you can get {{read(k1) = A, read(k2) = null}}). Atomicity of reads could be achieved only with pessimistic transactions and using the FORCE_WRITE_LOCK flag for reads. Probably better solution would be to always check for the presence of primary key and serve the session according to that. The check would have to be executed only after all entries are read.
                
> 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