I would expect using Shiro's ThreadState mechanism would be best for this - it is guaranteed to be cleared out at the end of each request by the ShiroFilter.
The sequence goes like this: AbstractShiroFilter calls subject.execute DelegatingSubject's execute method creates a SubjectCallable, which uses an internal ThreadState object to retain thread state during the request. When the execute method completes (and consequently, the request completes), the SubjectCallable ensures the ThreadState is cleared to keep the thread 'clean' in a thread-pooled environment. If the ThreadState can be used to retain a session, that could work. However, the same concept can be used to create thread-local-based cache in the SessionDAO. So it could work like this: 1. check the thread-local cache 2. check the normal cache 3. check the underlying data store The latter approach is probably a little easier to implement since it does not rely on too much of Shiro's Subject internals. HTH, Les On Mon, Oct 3, 2011 at 4:43 PM, matan_a <[email protected]> wrote: > Thanks Les for your quick reply! > > I do agree with your definition of what a cache should be doing. > > I think that i'm looking at the cache manager from a session clustering > perspective. Caching elements and efficient session clustering might not > have perfectly overlapping requirements. > > When i look at the CacheManager as a pure caching storage. It does what it > does perfectly fine and you're absolutely right. > > When i look at it as a session clustering solution, i'm still trying to > decide. Session clustering is pretty tightly coupled with a request > lifecycle..like querying the cluster if a session id doesn't exist locally, > caching it there, and possibly writing it back to the cluster when changes > are made. Those actions should only be done when necessary - and a local > copy should be used when it's not. Almost like a database... you don't run > the same SQL statements over and over again in the same request when you can > just do it once and save the value. I think the Jetty session clustering > solution is a good implementation of this. > > I guess that's implementation details and I could definitely add something > like this. I just have one disconnect that i'm sure you can help me with :) > > What do you suggest is the best way to keep track of request start and end > when dealing with the CacheManager? Ideally, I could wrap the CacheManager > with a DelayedRequestAware version that only read from the remote storage on > the first get() in a request, and only wrote to remote storage at the end of > the request (if there was any put() commands queued). It would save the > local variables in the Request context (thread?). > > Any suggestions would be great regarding this. I'd have to do quite a bit > of code hunting otherwise. > > Thanks again for supporting a great product! > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Cache-called-too-many-times-per-request-tp6851915p6855668.html > Sent from the Shiro User mailing list archive at Nabble.com. -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
