OTS and logging

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

Didn't have time or the opportunity to counter the assertion that the OTS spec does not refer to logging, which was repeatedly made at the Dublin F2F, as part of the argument for refusing to accept my issue on volatile/durable.

Just to set the record straight: if you read the OTS 1.5 spec, then you discover a vast number of references to logging, persistent storage of transactional state, stable storage, durable records and the like. Section 2.14 is particularly rich (and lengthy, and detailed). I've lost count. The cases of normal completion, failure recovery, and sub-coordination are all dealt with. However, this "not formal" part of the OTS specification, is by no means the only place where logging is referred to.

I give a few examples below for those who haven't time to look up the spec.

Alastair


Sample OTS "non-references" to logging

In section 2.8 "Resource interface"

2.8.1 commit

If the resource is able to write (or has already written) all the data needed to commit the transaction to stable storage, as well as an indication that it has prepared the transaction, it can return VoteCommit. After receiving this response, the Transaction Service is required to eventually perform either the commit or the rollback operation on this object. To support recovery, the resource should store the RecoveryCoordinator object reference in stable storage.

In the Glossary

Decided commit state:  A root coordinator enters the decided commit state when it has written a log-commit record; a subordinate coordinator or resource is in the decided commit state when it has received the commit instruction from its superior; in the latter case, a log-commit record may be written but this is not essential. Log-ready record (and contents): for an intermediate coordinator a log-ready record contains identification of the (superior) coordinator and of Resource objects (including subordinate coordinators) registered with the coordinator which replied VoteCommit (i.e., it excludes registered objects that replied VoteReadOnly); for a Resource object a log-ready record includes identification of the coordinator with which it is registered.

Log-commit record (and contents): A log-commit record contains identification of all registered Resource objects that replied VoteCommit.

Log-heuristic record: This contains a record of a heuristic decision either HeuristicCommit or HeuristicRollback.

Log-damage record:  This contains a record of heuristic damage i.e. where it is known that a heuristic decision conflicted with the decided outcome (HeuristicMixed) or where there is a risk that a heuristic decision conflicted with the decided outcome (HeuristicHazard).

(The following quotes are from the "not formal" part of the "Implementers' View", which is however referred to by formal parts relating to failure and recovery requirements)

2.14.1.1 General Principles

"The recording of information relating to the transaction which is required for recovery is described as if it were a log file for clarity of description; an implementation may use any suitable persistent storage mechanism."

Section 2.14.1.2 Normal Transaction Completion

In subsection "Coordinator role", after much prior detail:

"Before issuing commit operations on those registered resources that replied VoteCommit, the coordinator must ensure that the commit decision and the list
of registered resources—those that replied VoteCommit—is stored in stable storage."

and then, re participants, in subsection "Top-level completion"

1. Returning VoteCommit to prepare

Before a Resource object replies VoteCommit to a prepare operation, it must implement the following:
• make persistent the recoverable state of its recoverable object. The method by which this is accomplished is implementation dependent. If a
recoverable object has only transient state, it need not be made persistent.
• ensure that its object reference is recorded in stable storage to allow it to participate in recovery in the event of failure.
How object references are made persistent and then regenerated after a failure is outside the scope of this specification. The Persistent Object Service or some
other mechanism may be used. How persistent Resource objects get restarted after a failure is also outside the scope of this specification.
• record the RecoveryCoordinator object reference so that it can initiate recovery of the transaction later if necessary.
• the Resource then waits for the coordinator to invoke commit or rollback.
• A Resource with a heuristic outcome must not discard that information until it receives a forget from its coordinator or some administrative component.

and then, in the subsection "Subordinate Coordinator"

A subordinate coordinator does not make the commit decision but simply relays the decision of its superior (which may also be a subordinate coordinator) to resources registered with it. A subordinate coordinator acts as a recoverable server as described previously, in terms of saving its state in stable storage. A subordinate coordinator (or indeed any resource) may log the commit decision once it is known (as an optimization) but this is not essential.

and so on, and so forth