The big concern I have about memcache is that because it controls
storage external to the database there is no way to guarantee the cache
is consistent with the database.
I've found that letting applications add data to memcache and then
letting the database replace or delete keys seems to be the best
approach to minimize exactly this issue. Having two clients update the
cache is risky. Using triggers or using NOTIFY + tailing logs makes
this much more bullet proof.
This is similar to sending email in a trigger or on commit where you
can't be certain you send email always
and only on a commit.
While this is certainly a possibility, it's definitely closer to the
exception and not the normal instance.
In the database, we mark everything we do with a transaction id and
mark
the transaction id as committed in on operation. I see no way to do
that with memcache.
Correct. With an ON COMMIT trigger, it'll be easier to have a 100%
accurate cache. That said, memcache does exist out side of the
database so it's theoretically impossible to guarantee that the two are
100% in sync. pgmemcache goes a long way towards facilitating that the
cache is in sync with the database, but it certainly doesn't guarantee
it's in sync. That being said, I haven't had any instances of it not
being in sync since using pgmemcache (I'm quite proud of this, to be
honest *grin*). For critical operations such as financial
transactions, however, I advise going to the database unless you're
willing to swallow the financial cost of cache discrepancies.
-sc
--
Sean Chittenden
