4 ms·

One risk of not using expiration at all is that if the database is updated but the after_commit hook doesn't finish (crash, out of resources etc.) then the cach

by elbee 14y ago

One risk of not using expiration at all is that if the database is updated but the after_commit hook doesn't finish (crash, out of resources etc.) then the cached data remains outdated until the record is updated again (which could be never). Setting a generous TTL won't increase your load much, but will let problems like that eventually fix themselves.

hbrundage 14y ago
Core dev on IdentityCache here. Excellent point, and truth be told we hadn't considered setting an explicit expiry to let those unavoidable problems fix themselves. We do have a finite amount of space in memcached so the LRU there accomplishes something similar but gaining complete control over the expiry duration does make sense for the reasons you listed. Truth be told however I think I value the flip side of explicit expiry more: we can use any corrupt/un-updated information for debugging which we have done and found really useful in the past. We're also in a way forced to deal with anything which might interrupt our after_commit hooks instead of letting the problem just go away in a day. Hooks firing is also critical for other services we have (like elastic search) that rely on them, and for which I'd rather not create other auto-healers for. Thanks for the intelligent suggestion!
- elbee 14y ago
  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...
  - hbrundage 14y ago
    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.

by elbee 14y ago

hbrundage 14y ago

Core dev on IdentityCache here. Excellent point, and truth be told we hadn't considered setting an explicit expiry to let those unavoidable problems fix themselves. We do have a finite amount of space in memcached so the LRU there accomplishes something similar but gaining complete control over the expiry duration does make sense for the reasons you listed. Truth be told however I think I value the flip side of explicit expiry more: we can use any corrupt/un-updated information for debugging which we have done and found really useful in the past. We're also in a way forced to deal with anything which might interrupt our after_commit hooks instead of letting the problem just go away in a day. Hooks firing is also critical for other services we have (like elastic search) that rely on them, and for which I'd rather not create other auto-healers for. Thanks for the intelligent suggestion!

elbee 14y ago
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...
- hbrundage 14y ago
  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.