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


---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to