Saying *NO* to stale data

Michael Carter cartermichael at
Wed Jul 5 12:30:06 UTC 2006


I'm having a hard time understanding how to ensure that I avoid stale data.

Here is a scenario that will hopefully get right to the point.


A user with id 1 makes two simultaneous requests which we'll call request A
and request B: A posts a message to some forum and B changes the user's
email address. Lets assume that a valid User object exists under the key
"user_1". Here is a chronological list of events as they occur in request A
and B

1. A: user = memcached.get("user_1")
2. B: user = memcached.get("user_1")
3. B: = "newemail", user.lastAction = now
4. B: SQL update on user id=1
5. B: memcached.set("user_1", user)
6. A: user.lastAction = now
7. A: SQL update on user id=1
8. A: memcached.set("user_1", user) *** Here lies the problem

Now the memcached version of user_1 has stale data for the email address.

Is there a built-in or standard way of addressing this?

Does this sound valid:

1. When an object comes from memcached, keep an original copy of the object.
2. When setting an object to memcached, perform another get and ensure that
the original copy is the same as the one that came out.
3. If so, then do the set. If not, then expire the entry.

This still leaves a small hole open for however long it takes to perform the
get, comparison, and subsequent set , but it seems much less likely for
stale data to get through.

The final solution is to just expire the data whenever its updated, but that
seems awfully wasteful.

What are you thoughts on this?

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the memcached mailing list