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

5080RE: [rest-discuss] Re: transactions with REST

Expand Messages
  • Hugh Winkler
    Jun 4, 2005
    • 0 Attachment
      > REST (and even SOAP) calls are typically of long duration. This is
      > exacerbated if the invocation is going across the internet.
      >
      > In that situation, it is usually considered very poor design to hold a
      > transaction and tie up the resources on the back end.
      >

      It would be astonishingly poor design if your server held open a transaction
      in the underlying database across these calls. But you don't have to
      implement it that way. Nic's original post modeled the transaction as just
      another resource, so you could come back and commit that resource even days
      later -- I'm sure the implementation would just implement its own simple
      sort of transaction log and execute it on commit -- easy. You'd probably
      want to combine this model with one of the reliable HTTP ideas floating
      around.

      > Better bet is to keep the granularity of your REST (or WS) calls coarse
      > enough that the transaction is handled entirely by the back end.
      >
      > It points to your colleage thinking of the world in local RPC terms. That
      > doesn't fly very well in a distributed system. You might want to point
      > him
      > at the Fallacies of Distributed Computing (from Peter Deustch, extended
      > by
      > James Gosling):
      >
      > 1) The network is reliable.
      > 2) Latency is zero.
      > 3) Bandwidth is infinite.
      > 4) The network is secure.
      > 5) Topology doesn't change.
      > 6) There is one administrator.
      > 7) Transport cost is zero.
      > 8) The network is homogeneous.
      >

      Excellent list!


      Hugh
    • Show all 19 messages in this topic