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.
