+1, Looks good to me. On 6 May 2015 at 11:34, Amila De Silva <[email protected]> wrote:
> Hi All, > > When caching is enabled on Gateway, KeyValidationInfoDTO object is kept in > the cache against a cache key having the following structure; > > cacheKey = accessToken + ":" + apiContext + "/" + apiVersion + resourceUri > + ":" + httpVerb + ":" + authLevel; > > This structure makes cache retrievals efficient, but poses several > problems when removing entries. > > For example, when removing an API subscribed under an Application, we have > to delete cache entries associated with that API. But since the cache key > is a composition of several parts, finding cache entries related to a given > API is not a straightforward task. > > With the existing implementation, following steps are performed when > removing entries linked with a particular API, > a. Finding all Applications the API is subscribed to > b. Getting all active tokens issued for those Applications. > c. Creating all possible cache keys that could be present in the key cache. > d. Calling cache.remove on all the keys created > > Since we have access to the database in which tokens are stored, we have > the ability of finding all the tokens associated with an API. But when > having a third party Key Manager, this option won't work. Therefore a > different mechanism is needed to find Cache entries associated with an API. > > Proposed solution is to introduce a second cache, which acts as an index > for the main (existing) cache. Structure of the existing cache and the > cache Key will remain the same. > > *Structure of the new cache * > > The combination of apicontext, version will be used as the cache key and > the entry will be an APIEntry. Structure of the APIEntry will be like this. > > [image: Inline image 4] > > When needed to delete cache entries for an API, first the Index cache will > be looked up using API context + version as the key. This will return all > the ApplicationEntries which are present in the main cache and also to > which the API has subscribed to. ApplicationEntry will have a list of cache > keys, which are present in the main cache, and which contains a token > obtained under the enclosing Application. > > We have to add entries to the Indexing cache at the same time we add a new > entry to main cache. > > Will explain how different invalidation tasks are performed by only using > these two caches in a mail to follow. > > Would highly appreciate your thoughts on this approach. > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
