HomeOracle Page 4 - Generic Architecture for Caching Table Data: Supercharge Your Cache
Conclusion - Oracle
In the first part of this series we started of by putting the basic structures in place for a cache and wrote some code to manage the cache. In this next part, we will extend the functionality of our cache.
When you create a cache, you should always implement a switch that allows you to set caching off when needed. I cannot tell you how much time this has saved me while debugging my code. When you do switch off the cache, make sure you also clear it out before continuing, else you might see some unexpected behavior and cause “memory leaks.”
Given that this is so useful, I always implement my caches with this functionality and so I have made it a part of the Caching Architecture, which now basically looks like this:
Create a cache.
Create a procedure to empty the cache.
Create a switch for the cache, a public procedure to set the switch and a function to verify what the switch is set to.
Create a read, write and query procedure.
Create a data retrieval function that uses the switch.
In the next part of this series we will add even more functionality to the cache and try to find solutions for some of the drawbacks we mentioned earlier.
Oracle 
Generic Architecture for Caching Table Data: Keeping It Real (and Small)
