[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: WS-AT: Is logging mandatory?
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".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]