Re^10: Randomization as a cache clearing mechanism (races)

I'm new to the concept of optimistic locking. The delete delay in memcached is a feature of delete command which allows specifying a delay during which all further adds, gets, replaces & deletes for this particular object which had been just deleted would fail. Does it look similar?

Anyway, I'm going to read about optimistic locks, they sound interesting.

Comment on Re^10: Randomization as a cache clearing mechanism (races) Select or Download Code

Replies are listed 'Best First'.
Re^11: Randomization as a cache clearing mechanism (optimistic locking) by tye (Sage) on Nov 22, 2004 at 15:23 UTC
Optimistic locking is useful for interfaces where you have a person interactively updating a record. You check out a copy of the record, give the user all the time in the world to work out what changes they want to make, then, when the user goes to apply the changes, if the record was changed after you checked out a copy, then you deny the update and force the user to start over. Those last steps need to be done atomicly which is usually where locks come into play. But just ensuring that update operations for any given record get processed one-at-a-time from a single queue will also make updates atomic. To handle delete requests with this, you'd need to keep a place-holder for deleted records that consisted only of the revision number. I'd just let the external code decide what it wants to use as a place-holder for deleted records and use the update operation instead of the delete operation. - tye	[reply]

Replies are listed 'Best First'.

Re^11: Randomization as a cache clearing mechanism (optimistic locking)
by tye (Sage) on Nov 22, 2004 at 15:23 UTC

Optimistic locking is useful for interfaces where you have a person interactively updating a record. You check out a copy of the record, give the user all the time in the world to work out what changes they want to make, then, when the user goes to apply the changes, if the record was changed after you checked out a copy, then you deny the update and force the user to start over. Those last steps need to be done atomicly which is usually where locks come into play. But just ensuring that update operations for any given record get processed one-at-a-time from a single queue will also make updates atomic.

To handle delete requests with this, you'd need to keep a place-holder for deleted records that consisted only of the revision number. I'd just let the external code decide what it wants to use as a place-holder for deleted records and use the update operation instead of the delete operation.

- tye

[reply]