Re: Independenttrans Reapplycompleted v. Synchronized COMS recovery

On 3/26/2008 2:42 PM, Crash wrote:
On Wed, 26 Mar 2008 09:31:21 -0700 (PDT), Tom
<thomasmschaefer@xxxxxxxxx> wrote:

I was researching something about COMS recovery and it appears to me
that once the database had concurrency there was little reason to use
sync recovery any longer. That is the recollection I had when
concurrency came out.

Anyone care to comment if there is still a place for sync. recovery in
a DMSII concurrency world?

Note I am not talking about not using Protected Input Queue as that is
a separate item.

Working from memory here (and would appreciate correction if I am
wrong) - is that with INDEPENDENTRANS set DMSII recovers the db to the
last completed transaction and COMS then represents all transactions
in progress or queued (if input queue protection is enabled) at the
time of failure.

With INDEPENDENTTRANS not set, DMSII rolls the database back to the
last syncpoint but I cant recall if it then rolls the database forward
using the AUDIT file. There is certainly no COMS transaction
recovery.

Crash.

Crash's explanation is not quite correct. INDEPENDENTTRANS gets its name from the fact that it keeps simultaneous DMSII transactions independent of each other. It does that by keeping all records that were locked by a transaction locked until the transaction completes (or is aborted). Therefore, no other transaction can update (or create or delete) a record that has been locked by another transaction until that other transaction commits. FIND statements do not lock records, but if you need repeatable read isolation, you can use the SECURE statement in place of FIND to obtained shared read locks for a transaction.

The other thing that INDEPENDENTTRANS does is eliminate DMSII ABORT exceptions. Without this option set, when one program terminates in transaction state, DMSII sends ABORT exceptions to all other programs currently in transaction state for that data base. The reason for this is that, since without INDEPENDENTTRANS transactions can overlap and interact, DMSII does not know how the non-completion of one transaction may affect the ACID properties of other concurrent transactions, so it nails them all. The thing that actually triggers ABORT is not the program terminating, but closing a data base while in transaction state (which of course BLOCKEXIT will do when a program terminates). You can generate an ABORT condition without killing the program by simply closing the data base and reopening it while in transaction state.

INDEPENDENTTRANS does not cause the data base to be recovered to the last completed transaction -- that's the job of the REAPPLYCOMPLETED option. Without REAPPLYCOMPLETED (and regardless of the setting of INDEPENDENTTRANS), DMSII will recover a data base to the last syncpoint or quiet point. That may mean that any transactions after the last syncpoint/quiet point which had previously been committed (i.e., for which the program successfully completed and END-TRANSACTION statement) could be rolled back, and the program would be responsible for resubmitting them. Note that, by definition, a syncpoint or quiet point is a point in time where no programs are in transaction state for the data base, so there cannot be any transaction interactions taking place.

What REAPPLYCOMPLETED does is force an audit buffer flush as part of every transaction commit. This assures that all of the data to recover a committed transaction will be present on the audit trail by the time control is returned to the application program after its END-TRANSACTION statement. This option requires that INDEPENDENTTRANS also be set. When both options are set, commit really means commit, and an application program can be assured that once it exits from an END-TRANSACTION statement, that transaction will stay in the data base.

The default behavior in DMSII when these two options are reset (which was your only choice until INDEPENDENTTRANS and REAPPLYCOMPLETED were implemented in, I think, Mark 3.7, ca 1986) is a very antiquated approach to recovery. It can be made to work in a batch environment, but obviously is a real pain in an interactive one. It was the problem of recovering committed transactions that had been rolled back that synchronized recovery in COMS (and the predecessor capability in GEMCOS) were primarily designed to address.

I agree that setting INDEPENDENTTRANS and REAPPLYCOMPLETED for a DMSII data base provides the bulk of the benefit that COMS synchronized recovery does. To add to the comment that Paul Skykis made on a separate thread concerning historical transaction recovery, however, you need to note that these DMSII options only protect the transaction once it has been completely processed and committed. They do squat for transactions that have been received by the system but are still queued for processing by a TP. Whether or not that consideration is important depends on your application, of course, but it's something you need to keep in mind.

Unless I have a compelling reason not to do so, I always set both options for DMSII data bases. They carry some overhead (especially REAPPLYCOMPLETED, as the END-TRANSACTION will wait until the audit buffer flush can be completed), but I consider the overhead well worth it. Handling transaction recovery in a DMSII application program without these two options is challenging and difficult to get right. Using these two options is a cheap and reliable way to avoid the hassle.
.

Relevant Pages