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 > >
