Skip to content

Guava Mongodb Caching in Grails

July 3, 2016

Basic cache expiration

Expiration in Guava happens when few specific methods (like get/size etc ) are called. It does happen with a timer.So if you set it to 5 mins, expiry may happen few seconds later , when next get comes for same key.

Here is what happens.
Thread A: Get the key. Key has expired, returns false, get lock on cachekey, store data (Data is now doubled as delete on eviction has not yet run)
Thread B: Eviction has taken place, all data gets deleted, data is now 0 in cache .

We used Locks for synchronized access. Synchronize guarantees one thread accesses 1 op at a time, but what it does not guarantee is the Sequence of our operations.
So we want eviction to complete before storage happens, or we want eviction to not delete the newly stored entities. But we only have cacheKey as identifier so how do we differentiate !.

I even checked the mongodb eviction policy but that is also not immediate – it runs every 60 seconds/ depending on load etc. and if immediate eviction with continuous polling or timer can be a costly operation both at the db end as well in the guava cache library, the only option out that is quick and easy is to keep timestamp.

That can only happen when timestamp is maintained in the entities. I remembered that timestamps can be created in domain objects.
But keeping timestamp in all the DO’s is meaningless because we don’t want to know time DO is created but the time cache is created, so what we really want is to keep timestamp in the cacheSignature.

So here could be the scenarios:
· Timestamp is created when the cache is inserted in DB & entry is put in map , so the stored DO’s will have timestamp field but all DO’s will have the same time stamp value indicative of when cache was created. This timestamp is inserted in cacheSignature prior to cacheMap entry put call.
· When get happens, those entries which are older than expiry time than current will not be fetched.
· When delete happens , those entries which are expired as per current timestamp get deleted.

At the time of get/and store/ and delete we use this timestamp feature to fetch selective data.
The other advantage of this approach over writing your own eviction code based on the timestamp is that the getter code will not need to wait for delete Operation to complete before returning results to user.

Advertisements
One Comment leave one →
  1. March 4, 2017 8:13 am

    🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: