The TwoPhaseCommit commit is used to insure consistent updates and/or reads across distributed architectures. The TwoPhaseCommit requires additional control data (headers) for the HTTP protocol, first to support transactions, and second to support distributed transactions. Support for the TwoPhaseCommit in REST is a requirement transactional operations that span atomic activities in a RestWorkflowController.    (2MD)

There is a list of references at the bottom.    (2ME)

I am positive that other people have already explored this territory in depth, but I was not able to find any HTTP specific solution. Briefly, this is how I see that TransactionSemantics? and the TwoPhaseCommit might be supported for HTTP/REST.    (2MF)

  1. POST a <transaction> entity to a server. If the server supports transactions and chooses to accept the entity as a new transaction, then it will return the URI of the resource that corresponds to that transaction. The <transaction> element should ideally support some attributes that indicate things such as the maximum duration for the transaction (timeout), etc. Those attributes might be part of the POSTed <transaction> entity or they might be filled in by the server to which the <transaction> entity was POSTed.    (2MG)

2. A new HTTP header is defined named 'Transaction'. Its value is the URI of the <transaction> resource. When this header is present, the origin server for the HTTP request MUST deny the request unless it supports transactional semantics.    (2MH)

3. All HTTP requests made with that header value are part of the same transaction.    (2MI)

4. To commit the transaction, POST a <commit> entity to the transaction resource.    (2MJ)

5. To rollback the transaction, POST a <rollback> entity to the transaction resource.    (2MK)

6. After a successful commit or rollback, the transaction resource is probably DELETEd.    (2ML)

7. If the transaction times out, then the server SHOULD notify the user agent that created the transaction (e.g., by POSTing a transaction timeout event entity to that user agent).    (2MM)

I see that the same kind of mechanism might be used to support a TwoPhaseCommit. However, for a TwoPhaseCommit the <transaction> entity would have to indicate that TwoPhaseCommit semantics were required and the server that provided the TwoPhaseCommit <transaction> entity would have to act as the TransactionManager?, i.e., it would hold references to the individual <transaction> resources managed during the TwoPhaseCommit.    (2MN)

All of this requires detailed modeling. My main point is that I see approaching this problem using a resource to represent the transaction, by placing a reference to the transaction in an HTTP header, and by requiring the origin servers to respect the transaction. Other twists might be requiring that the HTTP OPTIONS method identifies whether the server supports one or two phase transactions, etc.    (2MO)

By the way, in order for a server to support TwoPhaseCommit, it must be able to vote for commit or vote for rollback so that the TransactionManager? may examine the votes of all involved servers and make an overall commit / rollback decision.    (2MP)

Some References (please expand and annotate):    (2MQ)

--bryan thompson (BryanThompson)    (2MZ)