Browse Prior Art Database

Spawning Method for Transaction Processing

IP.com Disclosure Number: IPCOM000119626D
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 3 page(s) / 119K

Publishing Venue

IBM

Related People

Franaszek, PA: AUTHOR [+3]

Abstract

Disclosed is a method for transaction processing which uses simulation modes and transaction spawning in order to avoid any delays in performing I/Os due to locking.

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

Spawning Method for Transaction Processing

      Disclosed is a method for transaction processing which
uses simulation modes and transaction spawning in order to avoid any
delays in performing I/Os due to locking.

      In very high performance systems, processor performance is
increasing much more rapidly than I/O performance.  This will result
in the base response time for transactions (the response time when
there are no conflicts with other transactions) being largely
determined by I/O delays. Therefore, very high levels of concurrency
will be required to achieve adequate processor utilizations in such
systems. However, using current concurrency control policies, it will
eventually be impossible to achieve the necessary levels: as shown in
(1), the effective level of concurrency (the number of concurrent
transactions doing useful work) eventually decreases under
locking-based policies, as the total level of concurrency is
increased.

      In (2), an approach to this problem is described based on the
principle of minimizing lock-holding times.  This approach involves
having some transactions go through two phases:  an I/O phase in
which no locks are acquired, and in which it is expected that no I/O
will be required.  The current method is a more dynamic approach
which yields improved performance.  We use the following terminology
and basic mechanisms.
Phases:    A transaction may go through one or more phases after it
enters the system, with each succeeding phase entered only if it
failed to commit in the previous phase. Certain transactions (such as
transactions that are computationally expensive, or transactions that
have stringent response time requirements) may be started in the
second (or higher) phase.
Priorities:When a conflict occurs between two transactions, the con
flict may be resolved by the use of priorities.  The prior
ity of a transaction may depend on its phase, its starting time,
whether it is waiting, and whether it had a spawn (see below) that
completed.
Simulation:As described in (2), a transaction runs in simulation mode
by running without requesting locks, in effect simulating what it
would do if it were the only transaction in the system.  To this end,
it may optionally operate on a logical snapshot of the database as it
existed at the time simulation mode was entered (this option would
only be required in certain types of systems, as discussed in 2).

      The primary purpose of running in simulation mode is to perform
I/Os that would otherwise have to be done in a later phase or by the
parent of a spawn (see below).
Spawning:  When a transaction goes into a wait on a lock, it may
spawn a transaction that runs in simulation mode.  The waiting
transaction is called the parent.  The initial state of the spawn is
that of the parent immediately preceding the lock request.

      The method of operation of the transaction processing system
can be summarized by the following two trans...