[
Lists Home |
Date Index |
Thread Index
]
K. Ari Krupnikov wrote:
> User A GETs a resource and edits it. User B GETs a resource and edits
> it. User A PUTs the modified resource back. User B PUTs her version of
> the modified resource back, unaware of A's edits. A's edits are lost
> without anyone noticing. What I want to happen is B to get a 409
> "Conflict" or some such.
Can you use an optimistic locking approach?
The resource representation includes an integer changestamp, managed by
the server. Everytime the server stores a representation, it increments
the changestamp. If you try to store a representation with a changestamp
that doesn't match the current one, the server give you the 409.
So in your scenario, User A GETs the resource with changestamp set to 1,
as does User B. User A PUTs the modified resource back. The changestamp
of 1 matches the server's value, so it accepts the change and increments
the changestamp. User B PUTs her version. Her changestamp of 1 no longer
matchs the version on the server, so the server returns 409. User B must
GET the current version and try again.
We were doing this with PowerBuilder and Sybase back in '92, but I guess
it should still work.
Jim
S/MIME Cryptographic Signature
|