Thanks. I've come to the same conclusion. That OAuth2Accessor needs to be persisted. When I stubbed out a NoOp OAuth2Cache the redirect_uri servlet request failed because it's trying to map a 'state' variable back to accessor. Ah, I keep finding fun stuff to implement.
doug On 12/13/11 11:58 AM, "A Clarke" <cla...@gmail.com> wrote: > Doug, > > Both in-memory and non-caching options could be acceptable. You could even > provide your own OAuth2Store implementation that doesn't even use the > OAuth2Persistence and OAuth2Cache interfaces. It's not really possible to > make a recommendation without knowing all the variables in your production > environment. I can say that from my personal experience (deploying shindig > into a clustered environment) it was necessary to implement more robust > caching of the OAuth2Accessor. > > > > > On Tue, Dec 13, 2011 at 10:30 AM, daviesd <davi...@oclc.org> wrote: > >> I understand that OAuth2Cache provides a mechanism for implementing a cache >> that the OAuth2Store uses to limit requests to the OAuth2Persister. >> However, if my OAuth2Persister implementation uses JPA or some other >> persistence model that already has caching built-in, the OAuth2Cache is >> redundant and probably not desired. Especially if you have deployed >> multiple shindig servers serving up the same domain. You¹d then have to >> have ³stickiness² set to guarantee getting a value from the cache, >> otherwise >> it would just be hitting the persister anyway. >> >> So my question is... Can I provided an OAuth2Cache implementation that does >> nothing (other than return nulls when requesting objects)? Or would the >> in-memory implementation be sufficient for a production environment? >> >> Thanks, >> Doug >> >>
