If instead of a select you do a select for update I think this would be
transaction safe. Nothing would be able to modify the data in the
database between when you do the SELECT and when you commit. If the
transaction fails the value in memcached will be correct.
Also, it's not clear if you're
My point was that there are two failure cases --- one where the cache
is
slightly out of date compared to the db server --- these are cases
where
the cache update is slightly before/after the commit.
I was thinking about this and ways to minimize this even further. Have
memcache clients add
On Nov 21, 2004, at 11:55 PM, Sean Chittenden wrote:
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.
While an exception, this is a very real possibility in day to day
operations. The absence of any feedback or balancing mechanism between
the database and cache makes it impossible to know that they are in sync
and even a small error percentage multiplied over time will lead to an
ever
Pierre-Frédéric Caillaud wrote:
While an exception, this is a very real possibility in day to day
operations. The absence of any feedback or balancing mechanism between
the database and cache makes it impossible to know that they are in sync
and even a small error percentage
Josh Berkus wrote:
Michael,
Still, it seems like a convenient way to maintain cache coherency,
assuming that your application doesn't already have a clean way to do
that.
Precisely.The big problem with memory caching is the cache getting out of
sync with the database. Updating
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
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
So What does memcached offer pgsql users? It would still seem to offer
the benefit of a multi-machined cache.
Ack, I totally missed this thread. Sorry for jumping in late.
Basically, memcached and pgmemcache offer a more technically correct
way of implementing query caching. MySQL's query
On 17 Nov 2004 03:08:20 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
So memcached becomes a very good place to stick data that's read often but
not
updated often, or alternately data that changes often but is disposable.
An
example of the former
On November 16, 2004 08:00 pm, Michael Adler wrote:
http://pugs.postgresql.org/sfpug/archives/21.html
I noticed that some of you left coasters were talking about memcached
and pgsql. I'm curious to know what was discussed.
In reading about memcached, it seems that many people are using
On Wed, Nov 17, 2004 at 09:13:09AM -0800, Darcy Buskermolen wrote:
On November 16, 2004 08:00 pm, Michael Adler wrote:
http://pugs.postgresql.org/sfpug/archives/21.html
I noticed that some of you left coasters were talking about memcached
and pgsql. I'm curious to know what was
Michael,
Still, it seems like a convenient way to maintain cache coherency,
assuming that your application doesn't already have a clean way to do
that.
Precisely.The big problem with memory caching is the cache getting out of
sync with the database. Updating the cache through database
Michael,
So What does memcached offer pgsql users? It would still seem to offer
the benefit of a multi-machined cache.
Yes, and a very, very fast one too ... like, 120,000 operations per second.
PostgreSQL can't match that because of the overhead of authentication,
security, transaction
On Tue, 16 Nov 2004 21:47:54 -0800, Josh Berkus wrote:
So memcached becomes a very good place to stick data that's read often but
not
updated often, or alternately data that changes often but is disposable. An
example of the former is a user+ACL list; and example of the latter is web
15 matches
Mail list logo
