[ https://issues.jboss.org/browse/ISPN-4132?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-4132: ------------------------------------ "So at any time it might make sense to keep in memory some of the attributes of S, but not all of them." Not really. In WF/EAP, the sessions to be passivated are primarily expected to be abandoned sessions, that is, session that I expect to eventually expire. Our primary use case for passivation is *not* as a means to handle more active sessions that a given server can keep in memory - but rather to handle the abandoned, but not yet expired sessions. In this way, I would typically prefer to evict all entries of a presumably abandoned session over the attributes of an active session that have not been accessed recently. The likelihood that the former will be accessed before the latter is typically low. But no, there isn't anything in the JEE standard about how one specifies how sessions are passivated. Your point about this being too complex is certainly valid, so let's try a different tack... What if we had the ability to specify that a given cache entry was never to be passivated automatically (i.e. like an immortal cache entry, but for eviction purposes)? Infinispan would then passivate based on a max-size of "auto-evictable" cache entries (i.e. some subset of the total entries in memory). This way, I can leverage a passivation callback to manually passivate the non-auto-evictable session attributes for a given session and still be able to define my eviction settings based on a maximum number of sessions. WDYT? -- 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