Re: Do we need transaction support in LDP?

On 5/9/13 5:46 PM, Ashok Malhotra wrote:
>
> On 5/9/2013 3:03 PM, Wilde, Erik wrote:
>> - one popular opinion is that if you look at transactions for your REST
>> service, you have a design-level granularity problem. this means that if
>> you want to create a scope that extents beyond a single interaction, 
>> then
>> your interaction granularity is too small, and you should design
>> representations that represent that bigger scope, so that you can handle
>> everything in just one interaction. (in the popular shopping example, 
>> this
>> translates to the client handling all shopping cart contents as
>> application state, and then submitting the complete shopping cart 
>> contents
>> in one request when checking out.)
> I don't think you can do that, in general, for LDP.  For example, you 
> could update the assets
> and the liabilities collections and the server could go down after it 
> updated the assets but before
> it updated the liabilities leaving the data in an inconsistent state.
>
> I think you are saying that you do all updates on the client and then 
> send to server as a single
> bundle.  Yes, that would work but I don't know how to bundle a bunch 
> of PUTs, POSTs and
> DELETEs into a single interaction.
>
> I agree that this can get messy with distributed transactions etc. but 
> we need some sort of ACID
> guarantee.  What should we do?

Leave it to the LDP compliant server to handle, since this is seriously 
out of scope for LDP  :-)

Kingsley

>
> Ashok
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen