New Issue: WS-AT: Is logging mandatory?

[Alastair Green <alastair.green@choreology.com>]

Issue name -- WS-AT: Is logging mandatory?

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL 
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

Target document and draft:

Protocol:  WS-AT

Artifact:  spec

Draft:

WS-AT CD 0.1 uploaded

Link to the document referenced:

http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17325/wstx-wsat-1.1-spec-cd-01.pdf

Section and PDF line number:

Whole spec, and specifically:

Section 10, "State Tables", Coordinator View table, between ll. 503 and 
504, Participant View table, between ll. 510 and 511.


Issue type:

Design / Editorial


Related issues:

New Issue: WS-AT: Internal events and actions undefined


Issue Description:

WS-AT spec does not specify policy or approach to logging. What is the 
intent, and how should it be reflected in the specs?


Issue Details:

WS-AT spec only mentions logging in passing, or implicitly.

ll. 393 - 394,(Section 7, "Security Model"):

"The participant can only prove its identity to the coordinator when it 
indicates that the specified transaction is not in its log and assumed 
committed."

In the state tables the undefined internal events "Write Done" and 
"Write Failed" might be taken to mean "persistent write done" and 
"persistent write failed" -- or then again they might be taken to mean 
"everything still fine" and "something went wrong".

Recovery (usually taken to mean crash recovery, and therefore implying 
persistent records) is mentioned in this sense only once, as follows 
(ll. 221-223, Section 4.3.3. "2PC Diagram and Notifications"):

"Replay -- Upon receipt of this notification, the coordinator may assume 
the participant has suffered a recoverable failure. It should resend the 
last appropriate protocol notification."

The design intent may have been either of the following:

A. Do not mandate any persistence or recovery strategy -- the protocol 
should be capable of being run in a volatile, no log manner, as well as 
using conventional logging techniques. (Dropping the D of ACID).

B. We all know that we mean to log, so let's not bother to mention it.

I believe A. is the correct design intent expressed by the input 
document authors at the inaugural TC meeting in November, and editorial 
changes should be made that clarify that intent.


Proposed Resolution:

a) Amend ll. 94 - 95 to delete the words "not persistent and" from the 
following sentence:

"The actions taken prior to commit are only tentative (i.e., not 
persistent and not visible to other activities)."

b) Insert after l. 104 a new paragraph as follows:

"While most atomic transaction systems use persistent logs to ensure 
consistent execution of transaction completion in the face of 
process/processor failure, WS-AtomicTransaction does not mandate any 
persistence policy or strategy. Its protocols are capable of being 
executed by endpoints which do log, and by those that do not. Quality of 
service with respect to crash recovery is left as an implementation, 
deployment and run-time issue."

c) Change name of state table actions "Write Done" and "Write Failed" to 
"Decision Recorded" and "Decision Unrecorded".