[Catalyst] Dispatching with Chained vs HTTP method

Adam Clarke adam.clarke at strategicdata.com.au
Wed May 7 09:02:46 BST 2008


On 07/05/2008, at 3:57 PM, Toby Corkindale wrote:

> On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote:
>>
>> The solution suggested in "Restful Web Services" is to POST to a  
>> "factory"
>> resource which creates you with a transaction resource. e.g. "POST
>> /transactions/account-transfer" returns "Location:
>> /transactions/account-transfer/11a5", where the 11a5 is a unique
>> transaction identifier.
>>
>> Then "PUT /transactions/account-transfer/11a5/accounts/checking/ 
>> 11", where
>> 11 is the account identifier. The body carries the transaction  
>> details, in
>> the example the balances are adjusted absolutely, i.e.  
>> "balance=150". A
>> similar PUT is sent for the other account.
>>
>> Once the required components of the transaction have been PUT it is
>> possible to rollback by DELETEing the transaction resource or  
>> commit it by
>> putting "committed=true" to the resource.
>>
>> While seeming a bit fiddly, it does keep the state on the client  
>> and allows
>> the client to make (at least some of) the commit / rollback  
>> decision rather
>> than (only) the server.
>
> I've read parts of RESTful Web Services, but not that bit.. I'll  
> have to go
> back and look.
>
> I wonder how one goes about implementing such a transaction on the  
> server
> side.. One would not want to lock DB rows indefinitely, waiting for  
> the client
> to finally complete the transaction. But if one just recorded the  
> queries and
> then executed them all (internally) at the end, then other risks  
> exist, eg:

I haven't done this before, but I have thought about it a bit. I think  
I would handle this as a two-phase commit. PostgreSQL has "PREPARE  
TRANSACTION" which allows you to start a transaction and assign it a  
"transaction_id" for use with a subsequent "COMMIT TRANSACTION". I  
would also use Multi-Version Concurrency Control (MVCC) rather than  
any kind of blocking locks to minimise the impact of the longer  
transaction lifetime.

This would at least keep a good deal of the hard work in the DB.

Cheers
--
Adam



More information about the Catalyst mailing list