Browse Prior Art Database

Distributed Transaction Integrity over Cold Start

IP.com Disclosure Number: IPCOM000116642D
Original Publication Date: 1995-Oct-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 55K

Publishing Venue

IBM

Related People

Banks, T: AUTHOR [+5]

Abstract

In a transaction processing system, a transaction is a recoverable piece of work which should be consistently committed or aborted. If part of a transaction commits and another part of the same transaction aborts, then the transaction is said to have lost its integrity.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Distributed Transaction Integrity over Cold Start

      In a transaction processing system, a transaction is a
recoverable piece of work which should be consistently committed or
aborted.  If part of a transaction commits and another part of the
same transaction aborts, then the transaction is said to have lost
its integrity.

      A transaction may be distributed across multiple systems.
Again, the parts of the transaction should all commit or all abort
regardless of which system they run on.

      If one of the systems involved in a distributed transaction is
cold started, then there are two impacts on the transaction
integrity:
  1.  Updates on the cold-started system may be committed or aborted
       without reference to whether the transaction commits or
aborts.
  2.  Other systems will not be able to resynchronise usefully with
       the cold-started system since the cold start has destroyed the
       resynchronisation information.

      The problem of local updates possibly going in the wrong
direction is, for the moment, insoluble since a cold start destroys
too much state to allow the necessary information to survive.

      However, the resynchronisation information may be kept
completely on the log.  At cold start, the log may be scanned and
resynchronisation information carried forward into the current run.
The solution disclosed here avoids the carrying forward of local
update information on the log by "capping...