[
https://issues.apache.org/jira/browse/SHIRO-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607852#comment-13607852
]
Les Hazlewood commented on SHIRO-317:
-------------------------------------
You're right Mark, I think associating it with a request is probably the best
way to do this.
I've been tinkering with ideas for this (with an initial implementation) in the
317b branch: http://svn.apache.org/repos/asf/shiro/branches/SHIRO-317b/
Specifically look at the StandardSessionManager and StandardWebSessionManager
(temporary names until I can supplant the Default*SessionManager
implementations). The web session manager will only propagate changed sessions
to the underlying SessionDAO when there are no more requests that reference a
particular session. I want to clean up the concurrency related code a bit
first though, but at least you can see my ideas.
I'm trying to minimize the delay between when sessions are in use and when they
are propagated to the clustered cache, but not slam the cache at the same time.
My goal is that if one of the webapp instances dies, another webapp instance
can pick up the clustered session with little or no loss of information/state
and the end-user would never know.
I've also thought about having the session state be stored as separate
individual properties in the cache - i.e. cache key= sessionId.timestamp, cache
value = Date object (etc. for other relevant properties, like session
attributes). This way the cache is only updated with the latest data when
things change and other cache entries can remain cached locally (if supported).
Finally, I've also thought about having a CachingSessionDAO that uses 2 tiers
of caching: a tier 1 in-process JVM cache and a tier 2 networked cache. The
network cache would only be 'hit' on write operations, performing a read only
if the session isn't in the tier 1 cache.
I'm also very open to suggestions!
> Read session from cache once per request
> ----------------------------------------
>
> Key: SHIRO-317
> URL: https://issues.apache.org/jira/browse/SHIRO-317
> Project: Shiro
> Issue Type: New Feature
> Affects Versions: 1.1.0, 1.2.0, 1.2.1
> Reporter: Luke Biddell
> Assignee: Les Hazlewood
> Priority: Minor
> Fix For: 1.3.0
>
>
> As per our discussion on the mailing thread, I've wired up my sessions to be
> stored in memcached (membase in the longer term). On a per request basis I'm
> seeing approximately 5 hits on my cache to retrieve the session. I would
> expect to see only one hit per threaded request, with the session stored as a
> thread local.
> For distributed caches this saves on network calls and for local caches it
> will save on potential lock contention.
--
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
