The default session timeout is 30 minutes, as is typical for most session environments (e.g. nearly all servlet containers), so we just kept that since most people expect it. But this timeout can be easily configured to any millisecond value, or disabled entirely (not really advised though, since some other process would need to clean up the orphans this setting would cause). If necessary, you can also control the timeout on a per-session basis.
The system-wide timeout can be dynamically changed at runtime and will be reflected for all newly created sessions after the new value is set. Existing sessions created before the system-wide timeout change are not affected - they retain their original timeout setting and their timeout can only be changed by calling setTimeout on each of these sessions. If you require changing all existing sessions via a single method call, please open a feature request. The session does get modified on every user request to update the session's last access timestamp. This is required in order for session validation to work correctly to determine when a session times out due to inactivity. In web applications, the Shiro Filter does this update automatically via the session.touch() method. For non web environments (e.g. for RMI) something else must call the touch() method to ensure the session validation logic functions correctly. HTH! Les On Tue, Sep 14, 2010 at 4:57 PM, Mike K <[email protected]> wrote: > > What are the lifetimes of the Shiro sessions? > I am wondering if the session gets modified with every user request. > This is of interest as I am looking at using ZooKeeper to manage session > state and this would impact the invalidation/ propagation strategy. > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/session-lifetime-tp5532601p5532601.html > Sent from the Shiro User mailing list archive at Nabble.com. >
