Re: Do we need transaction support in LDP?

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?

Ashok

Received on Thursday, 9 May 2013 21:47:11 UTC