Subclass template hook in case per-session timeout is not based on {@link hunt.shiro.session.Session#getTimeout()}. <p/> <p>This implementation merely returns {@link hunt.shiro.session.Session#getTimeout()}</p>
Looks up a session from the underlying data store based on the specified session key.
If using the underlying default <tt>SessionValidationScheduler</tt> (that is, the {@link #setSessionValidationScheduler(SessionValidationScheduler) setSessionValidationScheduler} method is never called) , this method allows one to specify how frequently session should be validated (to check for orphans). The default value is {@link #DEFAULT_SESSION_VALIDATION_INTERVAL}. <p/> If you override the default scheduler, it is assumed that overriding instance 'knows' how often to validate sessions, and this attribute will be ignored. <p/> Unless this method is called, the default value is {@link #DEFAULT_SESSION_VALIDATION_INTERVAL}.
@see ValidatingSessionManager#validateSessions()
The default interval at which sessions will be validated (1 hour); This can be overridden by calling {@link #setSessionValidationInterval(long)}
Scheduler used to validate sessions on a regular basis.
Returns the EventBus used to publish SessionEvents.
Sets the EventBus to use to publish SessionEvents.
Publishes events on the event bus if the event bus is non-null, otherwise does nothing.
Creates a new {@code Session Session} instance based on the specified (possibly {@code null}) initialization data. Implementing classes must manage the persistent state of the returned session such that it could later be acquired via the {@link #getSession(SessionKey)} method.
Template method that allows subclasses to react to a new session being created. <p/> This method is invoked <em>before</em> any session listeners are notified.
Returns the session instance to use to pass to registered {@code SessionListener}s for notification that the session has been invalidated (stopped or expired). <p/> The default implementation returns an {@link ImmutableProxiedSession ImmutableProxiedSession} instance to ensure that the specified {@code session} argument is not modified by any listeners.
Notifies any interested {@link SessionListener}s that a Session has started. This method is invoked <em>after</em> the {@link #onStart onStart} method is called.
Performs session validation for all open/active sessions in the system (those that have not been stopped or expired), and validates each one. If a session is found to be invalid (e.g. it has expired), it is updated and saved to the EIS. <p/> This method is necessary in order to handle orphaned sessions and is expected to be run at a regular interval, such as once an hour, once a day or once a week, etc. The "best" frequency to run this method is entirely dependent upon the application and would be based on factors such as performance, average number of active users, hours of least activity, and other things. <p/> Most enterprise applications use a request/response programming model. This is obvious in the case of web applications due to the HTTP protocol, but it is equally true of remote client applications making remote method invocations. The server essentially sits idle and only "works" when responding to client requests and/or method invocations. This type of model is particularly efficient since it means the security system only has to validate a session during those cases. Such "lazy" behavior enables the system to lie stateless and/or idle and only incur overhead for session validation when necessary. <p/> However, if a client forgets to log-out, or in the event of a server failure, it is possible for sessions to be orphaned since no further requests would utilize that session. Because of these lower-probability cases, it might be required to regularly clean-up the sessions maintained by the system, especially if sessions are backed by a persistent data store. <p/> Even in applications that aren't primarily based on a request/response model, such as those that use enterprise asynchronous messaging (where data is pushed to a client without first receiving a client request), it is almost always acceptable to utilize this lazy approach and run this method at defined interval. <p/> Systems that want to proactively validate individual sessions may simply call the {@link #getSession(SessionKey) getSession(SessionKey)} method on any {@code ValidatingSessionManager} instance as that method is expected to validate the session before retrieving it. Note that even with proactive calls to {@code getSession}, this {@code validateSessions()} method should be invoked regularly anyway to <em>guarantee</em> no orphans exist. <p/> <b>Note:</b> Shiro supports automatic execution of this method at a regular interval by using {@link SessionValidationScheduler}s. The Shiro default SecurityManager implementations needing session validation will create and use one by default if one is not provided by the application configuration.
Called when this object is being destroyed, allowing any necessary cleanup of internal resources.
Default business-tier implementation of the {@link ValidatingSessionManager} interface.