Loading ...
Sorry, an error occurred while loading the content.

5083Re: [rest-discuss] Re: transactions with REST

Expand Messages
  • Nic Ferrier
    Jun 4, 2005
      Jan Algermissen <jalgermissen@...> writes:

      > - if transactions across unrelated systems indeed make sense in a
      > networked system and how we do them with REST.

      The system I outlined could be easily made to do distributed

      Just allow a GET against /transactions to return the current
      in progress transactions. A discovery protocol if you like.

      Once you know what transaction you want to join in with then you just
      POST an item into it as I previously described.

      Some of this could be formalized, the list of extant transactions
      could be defined by DTD or schema, the current state of a transaction
      could be modeled by a namespace document.

      Anyone think that it's worthwhile specing these out and doing a demo

      > BTW: can a single HTTP method call considered to be atomic? If a PUT
      > fails, can I assume that nothing of the operation succeded? Can a
      > POST be partially processed and still return with an error? Or is
      > this allways either/or?

      Single HTTP methods can never be truly atomic because HTTP doesn't
      necessarily care about whether you recieve the response or not.

      You can implement the methods to be atomic on the program side.

      But unless you write your own webserver, and write it to be really
      smart, then you won't know that the client definitely receieved the
      response from your method implementation.

      It's not just implementing a server to roll back the operation
      if the response was not completly transmitted to the client... there
      are no semantics for that.

      For example, if the client gets the status code, and if the status
      code is an error (so the client knows the operation failed) but the
      client doesn't get the rest of the response, is that a failure to
      send, or not?

      That's why you need something else on top, to implement transactions
      (well, you do when you need this kind of behaviour).

      One of the reasons why I think my suggestion works is that it's able
      to do 2 phase commit quite well. The final commit can be:

      x = GET ; PUT x ; assert x == GET

    • Show all 19 messages in this topic