in reply to Randomization as a cache clearing mechanism
Your question is interesting to me because I'm thinking of implementing a similar caching system. As such, I'm curious why you decided not to just clear a node out of the cache when doing any operation that would make the cache out of date, for example updates to the node. Then you wouldn't have to keep any special record in the database.
My guess is that you have so many potentially cache-invalidating operations that you didn't want to clear the cache on each of these operations because of the maintenance headache. So you've built a sort of event/trigger mechanism using a database table. Now the code that updates the database doesn't have to know about the code that maintains the cache.
My plan is to do all the cache management at the control layer -- eg the script that processes a new message will clear the cache of the message index -- but I'm worried this won't scale beyond a few scripts and I'll need to go with a more formal event-driven system like yours.
Interesting problem, sorry I don't have any direct feedback.
|
|---|