[ https://issues.jboss.org/browse/ISPN-694?page=com.atlassian.jira.plugin.s... ] Dan Berindei commented on ISPN-694: ----------------------------------- [~william.burns] right, I was thinking that without key affinity the requests will go to random nodes, so the chance of hitting either owner is the same. But I guess if {{maxIdle}} is on the same scale as the average access interval, it's still possible to get a big difference in expiration times. I do think that, for most of the users, using {{maxIdle}} and {{lifespan}} implies that a {{null}} value is always correct: should the user disable caching altogether, the application should still work. So I don't see the fact that an entry expires on different nodes at different times as a consistency problem, it's just that the user must have another source for the data in the cache. In fact, I'm not sure what a {{maxIdle}} expiration listener could do. It can't invalidate the values on the other owners, because it might actually be used there. It shouldn't reload the entry from the canonical source, like a {{lifespan}} expiration listener might do, because the notification itself tells it the entry isn't needed. So I wonder if we shouldn't design the expiration listeners to not fire on {{maxIdle}} expiration. For web server sessions as well, I think they need to be updated on each request with the last access time, so they could use {{lifespan}} instead of {{maxIdle}} for a sentinel entry and no expiration for the rest of the entries. -- 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