[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A question about REST and transaction isolation

• To: "K. Ari Krupnikov" <ari@c...>
• Subject: Re: A question about REST and transaction isolation
• From: Jim Ancona <jim@a...>
• Date: Mon, 09 Feb 2004 18:04:53 -0500
• Cc: xml-dev@l...
• In-reply-to: <86smhj3mcr.fsf@f...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE03F9F2F9@h...> <86smhj3mcr.fsf@f...>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

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

• References:
  • RE: A question about REST and transaction isolation
    • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Re: A question about REST and transaction isolation
    • From: ari@c... (K. Ari Krupnikov)

• Prev by Date: RE: A question about REST and transaction isolation
• Next by Date: RE: more silly questions
• Previous by thread: Re: A question about REST and transaction isolation
• Next by thread: Re: A question about REST and transaction isolation
• Index(es):
  • Date
  • Thread