Simple memory-based implementation of the SessionDAO that stores all of its sessions in an in-memory {@link ConcurrentMap}.
This implementation does not page to disk and is therefore unsuitable for applications that could experience a large amount of sessions and would therefore cause {@code OutOfMemoryException}s. It is
not recommended for production use in most environments.
Memory Restrictions
If your application is expected to host many sessions beyond what can be stored in the memory available to the JVM, it is highly recommended to use a different {@code SessionDAO} implementation whichuses a more expansive or permanent backing data store.
In this case, it is recommended to instead use a custom {@link CachingSessionDAO} implementation that communicates with a higher-capacity data store of your choice(file system, database, etc).
Changes in 1.0
This implementation prior to 1.0 used to subclass the {@link CachingSessionDAO}, but this caused problems with many cache implementations that would expunge entries due to TTL settings, resulting in Sessions that would be randomly (and permanently) lost. The Shiro 1.0 release refactored this implementation to be 100% memory-based (without {@code Cache} usage to avoid this problem.
@see CachingSessionDAO
@since 0.1