[ https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin.... ] 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. -- 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