Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
