Re: OAuth2Cache

[Michael Matthews <ma...@oclc.org>]

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" <cl...@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 <da...@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
>> 
>>