Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Data Consistency and Exchange Among Nested Transactions in a Database

IP.com Disclosure Number: IPCOM000043000D
Original Publication Date: 1984-Jun-01
Included in the Prior Art Database: 2005-Feb-04
Document File: 3 page(s) / 38K

Publishing Venue

IBM

Related People

Kim, W: AUTHOR [+4]

Abstract

This invention relates to a method for achieving data consistency and and data exchange among nested transactions in a database. The method steps include (a) checking out selected objects from the database, (b) downwardly committing one or more objects, (c) defining a new transaction and specifying its relation to previous transactions, if any; and (d) upwardly committing the modified object to the parent. Existing models of specialized transactions, such as engineering transactions, may support the same set of commands that conventional transactions support: BEGIN_TRANSACTION, END_TRANSACTION, ABORT, SAVE, and UNSAVE. An engineering transaction will be initiated with a BEGIN_TRANSACTION and terminated by an ABORT or END_TRANSACTION.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Data Consistency and Exchange Among Nested Transactions in a Database

This invention relates to a method for achieving data consistency and and data exchange among nested transactions in a database. The method steps include
(a) checking out selected objects from the database, (b) downwardly committing one or more objects, (c) defining a new transaction and specifying its relation to previous transactions, if any; and (d) upwardly committing the modified object to the parent. Existing models of specialized transactions, such as engineering transactions, may support the same set of commands that conventional transactions support: BEGIN_TRANSACTION, END_TRANSACTION, ABORT, SAVE, and UNSAVE. An engineering transaction will be initiated with a BEGIN_TRANSACTION and terminated by an ABORT or END_TRANSACTION. Initiation and termination of an engineering transaction are from a designer's private database system. A transaction CHECKs OUT design objects from the public database system. Upon completion of the transaction, the modified design objects are checked into the public database system. A transaction can SAVE changes any time within a transaction, and UNSAVE to an arbitrary SAVE point to back out the changes. This is enhanced by incorporating nested transactions. Two new commands (DOWNWARD COMMIT and UPWARD COMMIT) are introduced. A transaction DOWNWARD COMMITs a set of objects to its own 'semi-public' database for checkout by other transactions. The transactions which check out objects from a transaction's semi-public database become its dependent transactions; that is, they are its children in a transaction hierarchy. When a transaction UPWARD COMMITs a set of objects, it transfers (checks in) the objects to the semi-public database of its parent transaction. When the transaction ENDs, all the objects it has not already explicitly UPWARD- COMMITted are UPWARD-COMMITted to its parent transaction. Objects committed by DOWNWARD or UPWARD COMMIT cannot be backed out by UNSAVEs. Further, a transaction...