5080RE: [rest-discuss] Re: transactions with REST
- Jun 4, 2005
> REST (and even SOAP) calls are typically of long duration. This isIt would be astonishingly poor design if your server held open a transaction
> 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.
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
> Better bet is to keep the granularity of your REST (or WS) calls coarseExcellent list!
> 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
> at the Fallacies of Distributed Computing (from Peter Deustch, extended
> 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.
- << Previous post in topic Next post in topic >>