News for hackers. Stuff that matters.

A comment on IdentityCache: Improving Performance one Cached Model at a Time. Parent comment

Re:IdentityCache: Improving Performance one Cached Model at ... by elbee on Thursday April 04, 2013 @05:43PM (#5495497)
In some systems the problem is that you can never be guaranteed that the after_commit hook will always run. This is especially true in multi-server systems where the cache, database and front-end servers are separated. The front-end server can update the database and then completely die (power outage, networking, reboot) before talking to the cache.

On the other hand I can see how you would want to drive out bugs instead of just sweeping them under the carpet with auto-healing...

[ Parent | on HN ]
Re:IdentityCache: Improving Performance one Cached Model at ... by hbrundage on Friday April 05, 2013 @01:21PM (#5499709)
Indeed: it will never be 100%, so perhaps a very, very long TTL on the keys would be wise. We do end up flushing the cache incrementally if we ever ship a bug by accident or notice there is more in the cached blob than we want which I think accomplishes the same thing.
[ Parent | on HN ]