Subject: [drinks] Assuming we need multiple-operation transactions

From: Dean Willis <[email-masked]>
Date: Thu, 15 Sep 2011 10:31:12 -0500

The current SPPP protocol allows transactions to contain multiple
data-manipulating operations.

In Quebec, we agreed that the entire transaction is atomic. In other words,
if any part of the transaction fails, then none of the operations in that
transaction are commuted to the persistent data store.

So if a transaction on an empty datbase looks like:

Start transaction
  AddDestGrp A
  AddDestGrp B
End transaction

and the AddDestGrp B part fails, then the datastore would contain neither
DestGtp A nor B.

In other words, the transaction is atomic at the SPPP level.

But having the transaction be atomic at the SPPP level says absolutely
nothing about the binding between SPPP and an implementation protocol like
HTTP.

An implementation could validly model the SPPP transaction above as a single
operation or as multiple dependent operations. For example:

CREATE transaction 123FTY
APPEND "AddDestGrp A" to 123FTY
APPEND "AddDestGrp B" to 123FTY
DO 123FTY

Some implementation protocols might require breaking up the transaction this
way. Others might not allow it.

Consequently, the top level SPPP document must require neither modality. It
defines only what the transaction means at the SPPP level, not how they are
mapped into implementation-protocol transactions.

In practical terms, this means that while SPPP must be implentable in a
RESTful manner, that there is no hard requirement in the SPPP spec that each
SPPP transaction map to a single HTTP operation.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Thu, 15 Sep 2011 13:33:35 -0400

Dean,

Exposing the transaction handle opens up the system to the problem of "long running transactions". There is plenty of literature on the internet that discusses this problem. Also, this also makes the system susceptible to DoS attacks which I suspect IESG would not approve of. I don't think there is any size limit for the entity object in case there is a need to include many commands within a single HTTP request, if that is part of the concern.

Thanks,

-Syed

From: Dean Willis <[email-masked]<mailto:[email-masked]>>
Date: Thu, 15 Sep 2011 11:31:12 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [drinks] Assuming we need multiple-operation transactions

The current SPPP protocol allows transactions to contain multiple data-manipulating operations.

In Quebec, we agreed that the entire transaction is atomic. In other words, if any part of the transaction fails, then none of the operations in that transaction are commuted to the persistent data store.

Start transaction
  AddDestGrp A
  AddDestGrp B
End transaction

and the AddDestGrp B part fails, then the datastore would contain neither DestGtp A nor B.

But having the transaction be atomic at the SPPP level says absolutely nothing about the binding between SPPP and an implementation protocol like HTTP.

An implementation could validly model the SPPP transaction above as a single operation or as multiple dependent operations. For example:

Some implementation protocols might require breaking up the transaction this way. Others might not allow it.

Consequently, the top level SPPP document must require neither modality. It defines only what the transaction means at the SPPP level, not how they are mapped into implementation-protocol transactions.

In practical terms, this means that while SPPP must be implentable in a RESTful manner, that there is no hard requirement in the SPPP spec that each SPPP transaction map to a single HTTP operation.

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Sep 2011 11:11:02 -0500

On 9/15/11 12:33 PM, Ali, Syed Wasim wrote:

> Exposing the transaction handle opens up the system to the problem of
> "long running transactions". There is plenty of literature on the
> internet that discusses this problem. Also, this also makes the system
> susceptible to DoS attacks which I suspect IESG would not approve of. I
> don't think there is any size limit for the entity object in case there
> is a need to include many commands within a single HTTP request, if that
> is part of the concern.
>

My point is that this decision should be left to the designer of an 
implementation-protocol binding. It's not part of the problem-space of 
the abstract SPPP protocol.

Solving it (but only for SOAP) IS in the problem-space of an SPPP-SOAP 
binding.

The IESG has asked us to make sure that the abstract and binding 
documents are divided such that the abstract document is equally 
applicable to other bindings, such as REST.

We've shown at least one published technique by which multiple-operation 
transactions could be mapped to REST. That's enough to show that the 
abstract SPPP protocol is valid from an IESG perspective, assuming we 
don't have any other features in the "abstract" document that belong in 
a "binding" document instead.

If you want to design a SOAP-REST binding, then we can get into the 
debate on whether that binding should use transaction objects, or merely 
POST a sequence of operation descriptors for a transaction. I don't 
think "the group wants to do that right now, but I might be up for doing 
do it just as a thought exercise.

--
Dean