Re: Storing sessins in an RDBMS instead of an enterprise cache?

[syrineBS <be...@gmail.com>]

Hi,
Actually I am facing the same problem mentioned in the subject of this
conversation, I ask in the shiro mailing list, because I didn’t find an
answer to my question, anywhere.
I am a new user of Shiro, I use a jdbcRealm which I customized to connect to
a database, used for authentication and authorization, it works very well,
and I find Shiro very easy-to-use.
And now I need your help to manage user sessions. 

Actually, my application needs to store user session’s data in order to
trace the activity of user’s session (do session tracking).

I find in shiro documentation, that shiro implements SessionDAO , using
EnterpriseCacheSessionDAO class, which,  if I understand well, allows
storing session‘s activity in a cache .
*My question at this level is:* can I read/access data in the cache, and if
yes, how can I do it *?* 
(I am new to shiro, and a beginner developer) 

Then, I also find in the documentation that I can implement SessionDAO
class, to make my session data reside in a relational database. 
Les, in your first answer you said “if it your RDBS API does not perform
caching directly (e.g.using just raw JDBC), it is pretty much expected that
you will subclass the org.apache.shiro.session.mgt.eis.CachingSessionDAO”
I am actually in this case.
I don’t have any idea on how to do this. 
*My question is:* when I implement SessionDAO, how/where configure the
connection to the database, and how to configure create method to insert
data into the SESSION table *?*

Thanks!



Les Hazlewood-2 wrote
> Hi Garoad,
> 
> Yes you're right - this is very possible and there are more than a few
> that do it already, but the documentation in lower-level Session
> Management customization is lacking at the moment.  However, the
> solution is simple enough (I elaborate quite a bit below, so it looks
> more cumbersome than it really is - but it's really pretty easy):
> 
> 1.  Turn on native session management
> 
> If using a web.xml configured ShiroFilter, a DefaultWebSecurityManager
> is enabled by default, and that in turn defaults to piggybacking the
> servlet-container Sessions and not using Shiro's native session
> management.  In order to control Session persistence yourself, you
> need to ensure that you're running a 'native' SessionManager.  E.g. in
> INI:
> 
> [main]
> ...
> securityManager.sessionMode = native
> 
> This is only necessary if configuring Shiro as a ShiroFilter.
> Otherwise, native sessions are enabled by default.
> 
> 2.  Implement the org.apache.shiro.session.mgt.eis.SessionDAO
> interface to talk to your RDBMS.  If your RDBMS interaction API of
> choice implements caching behavior already (e.g. Hibernate w/ it's 1st
> and 2nd-level cache), you can implement the interface directly.
> 
> However, if it your RDBS API does not perform caching directly (e.g.
> using just raw JDBC), it is pretty much expected that you will
> subclass the org.apache.shiro.session.mgt.eis.CachingSessionDAO and
> then configure a CacheManager in Shiro:
> 
> This is because Shiro does not currently integrate with any
> Transaction Management APIs and so it can't have a 'thread local
> cache' of a Session instance bound to a Transaction context.  So that
> means _every_ session operation will hit your datasource unless you
> employ a cache.  Even if you only use the simple out-of-the-box
> Ehcache support, this is better than nothing.  This way the cache will
> alleviate constant hits on your RDBMS (which can easily occur 10 or
> more times during an average request).
> 
> Again, this caching concern only exists if your RDBMS API of choice
> does not already support caching.
> 
> 3.  Inject your session DAO into the native SessionManager and
> configure a CacheManager if necessary according to #2 above.  For
> example, in INI:
> 
> sessionDAO =
> com.mycompany.shiro.JdbcSessionDAOThatSubclassesCachingSessionDAO
> ...
> 
> # the following call is only necessary in a web-configured ShiroFilter
> (otherwise
> # a native session manager is already enabled):
> securityManager.sessionMode = native
> 
> # now that we're using a native SessionManager (wrapped by the
> # SecurityManager instance), inject the sessionDAO:
> securityManager.sessionManager.sessionDAO = $sessionDAO
> 
> #inject your cacheManager:
> securityManager.cacheManager = $myCacheManager
> 
> I hope that helps!
> 
> As to your 'DB is the central place' for sessions comment, I would
> really recommend that you look at a distributed cache - even Ehcache's
> networked version or Memcache at a minimum.  They are designed
> specifically for transient data that needs to be accessible locally as
> much as possible, but available on other nodes if necessary.  They are
> essentially a poster child for session clustering and there is almost
> no better solution.  You will have _much_ better performance from a
> distributed cache managing sessions than you will an RDBMS (this is my
> bread and butter for my 'day job' :))
> 
> I would only save to an RDBMS if you needed to do any kind of querying
> or reporting on sessions data, but I would still always front that
> RDBMS with a clustered cache for to performance.  Distributed caches
> are free and/or cheap (enought) these days with options like Memcache,
> Ehcache and Terracotta - I highly recommend going that route if you
> need clustered sessions.
> 
> Anyway, that's just a recommendation - you know your environment,
> project limitations and deployment environment better than I ever
> could.  I just wanted to put that out there as food for thought, and
> to potentially help anyone else pondering a solution if they have
> similar requirements.
> 
> Cheers,
> 
> -- 
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and
> Training:
> http://www.katasoft.com





--
View this message in context: http://shiro-user.582556.n2.nabble.com/Storing-sessins-in-an-RDBMS-instead-of-an-enterprise-cache-tp5645213p7580149.html
Sent from the Shiro User mailing list archive at Nabble.com.