I could use some feedback on how to implement the OAuth2Cache interface in the OAuth2 consumer implementation. Doug and I are following the approach outlined earlier where our OAuth2Cache is essentially a no-op implementation of OAuth2Cache where all methods do nothing, with the exception of the OAuth2Accessor-related methods. These methods are implemented to "cache" the OAuth2Accessors in a relational database (the serialized object is stored in a BLOB). All of this was done because our Shindig servers are running in a cluster (currently without sticky sessions) and we wanted the OAuth2Accessors available to all the servers.
The persistence of the OAuth2Accessor into the database seems to work ok. However I'm noticing behavior in Shindig that suggests this approach will not work (or a similar approach that stores the accessors external to the server's memory). In a couple different Shindig classes, I see where the OAuth2Accessor is loaded from the cache, modified, and then not updated in the cache. One example is in OAuth2CallbackServlet: the accessor is loaded, updated at the end of the request, and then the cache is never updated with the changes. Another example is in BasicOAuth2Request where the accessor is stored in the cache, then modified, and then not updated in the cache. So it appears that the OAuth2 consumer implementation is dependent on the OAuth2Accessor being cached in memory. We can easily provide an in-memory OAuth2Cache implementation and configure our load balancers to use sticky sessions. Can someone comment on any issues there might be with this approach? It appears that all the OAuth2-related servlets are initiated by the user's browser, which would allow the sticky sessions to work. Thanks in advance. Mike 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 >> >>
