Generic Architecture for Caching Table Data: Supercharge Your Cache

Things to look out for when using a cache

Although caching is a fabulous way to increase performance, it has a couple of drawbacks.  First of all, data in the cache can get out of sync with the data in the database: a record you cached might get updated or even removed from the database.  This is one of the reasons you should not use caching on transactional data that gets changed a lot.  These synchronization issues can result in “unpredictable” behavior of your code and are potentially very hard to debug.  Because we hide our caching logic, a fellow developer who is using your package might not understand why, when the database says “The Department Name of department 20 is R&D”, your procedure consistently returns that “The Department Name of department 20 is Research”.

A second issue with caching is that, by its very nature, it consumes memory.  This becomes a problem when either your cache becomes very big or there are many users who simultaneously, in separate sessions, use your package, spawning many caches.  Besides causing memory issues, big caches also tend to become slower, that is they do not scale very well.  This obviously defeats the purpose of having a cache in the first place so try to keep them as small as possible.

In a later part of this series we will try to implement solutions for these issues but for now, like a true developer, I first would like to try an easy solution.