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 doi
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 dat
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 percentag
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 incr
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
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
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
> a
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.
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 cachin
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 databas
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 wa
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 us
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
> > exampl
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 is a user+ACL list; and example of the latter is web
> session info
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
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 v
16 matches
Mail list logo
