Rich, I'm sure Les will respond with a much more detailed and correct response than this, but I thought I'd offer a few insights based on a previous implementation. In another life, I worked with Les on a project which used GigaSpaces, and we managed all of our session data in GigaSpaces. GigaSpaces was the system of record, for that project--no session data was ever stored in a database. Because GigaSpaces' spaces are separate entities (or can be) from the application, it was possible in our environment to do any necessary system maintenance without shutting down the spaces. In that environment, we did not use CacheSessionDAO. Instead, we built a GigaSpacesSessionDAO that implemented the QueryableSessionDAO interface (and, by extension, SessionDAO as well) directly. That DAO was injected with a GigaSpace object. We had an annotated @SpaceClass(persist = true) GigaSpacesSimpleSession that extended from Shiro's built-in SimpleSession class and added annotations as necessary. Our GigaSpacesSessionDAO read and wrote instances of our GigaSpacesSimpleSession from the cache, and we used GigaSpaces' SQLQuery support to simplify building the various queries that the DAO implementation required. We did not store the Subject itself in the database at any level, because it didn't have any important data associated with it. In our GigaSpacesSimpleSession class we stored the principal for the Subject, which, in our system, was the database primary key for a User object which contained all the user's pertinent data. The final piece of this puzzle was a GigaSpacesSessionFactory, which implemented the Shiro SessionFactory interface and was injected into the DefaultSessionManager to instantiate our GigaSpacesSimpleSession object instead of Shiro's standard SimpleSession class. This way, our DAO could simply cast the provided Session (interface) to GigaSpacesSimpleSession as necessary for its operations. Again, I'm sure Les will be able to expound on this (or maybe even suggest a newer, better way based on his much deeper understanding of the current state of Shiro and things he's learned since he and I wrote that implementation. Hope this helps,Bryan Turner
> Date: Wed, 27 Oct 2010 13:09:41 -0700 > From: [email protected] > To: [email protected] > Subject: Re: how to realize multi threaded single sign-on > > > Also looking at the implementation that is provided for EhCache, it looks > like I will need to implement 3 classes to make this work Cache, > CacheManager, and a CacheSessionDAO, correct? Also GigaSpaces make use of > their own annotations to insert POJOs into their IMDG (In Memory Data Grid). > I am assuming I will also have to create a POJO that contains a "Subject" > instance in order to insert this into their cache implementation. Am I at > least on the right track from a shiro point of view. > > thanks, > > Rich > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/how-to-realize-multi-threaded-single-sign-on-tp5204196p5680123.html > Sent from the Shiro User mailing list archive at Nabble.com.
