Bruce,
> 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. 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.
Well, some things ... ON COMMIT triggers, or messages with NOTIFY, would
improve the accuracy by cutting down on cached aborted transactions.
However, caching is of necessity imperfect. Caching is a trade-off; greater
access speed vs. perfect consistency (and any durability). There are cases
where the access speed is more important than the consistency (or the
durability). The answer is to use memcached judiciously and be prepared to
account for minor inconsistencies.
For that matter, as with other forms of cumulative asynchronous materialized
view, it would be advisable to nightly re-build copies of data stored in
memcached from scratch during system slow time, assuming that the data in
memcached corresponds to a real table. Where memcached does not correspond
to a real table (session keys, for example), it is not a concern at all.
--
Josh Berkus
Aglio Database Solutions
San Francisco