Browse Prior Art Database

Method for Performance Enhancement in the Parallel Execution of Static Database Transactions

IP.com Disclosure Number: IPCOM000113493D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 6 page(s) / 237K

Publishing Venue

IBM

Related People

Brosda, V: AUTHOR

Abstract

Described is a method for avoiding wait states in the execution of static transactions. The essential idea is the exploitation of the bahavior of the transactions already known at compile time in conjunction with the workspace concept.

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

Method for Performance Enhancement in the Parallel Execution of Static
Database Transactions

      Described is a method for avoiding wait states in the execution
of static transactions.  The essential idea is the exploitation of
the bahavior of the transactions already known at compile time in
conjunction with the workspace concept.

      In database systems, competing accesses to shared data are
implemented through the introduction of transactions and their
management by an internal transaction manager in order to avoid
access conflicts.  A transaction here comprises a sequence of
(elementary) read and write accesses, which are executed in isolation
and either in their entirety or not at all (atomarity).  A user has
the opportunity of specifying the beginning and the end of a
transaction and to complete its execution with a confirmation
("commit") or by retracting the effects of its execution ("roll
back").  A transaction thus implements an atomic transition between
consistent database statuses.

      In order to distribute the response times equally where there
are (normally) fewer processors than transactions to be executed, the
transactions arriving in a specific period are handled in parallel
(but interleaved) (see example 1).  Naturally, in this event, it is
necessary to ensure that the properties of a transaction sketched out
above (above all isolation) are not prejudiced by this procedure.  As
a rule, the requirement is raised that a sequential process sequence
leading to the same result as interleaved processing must exist.  In
practice, this serialisability is generally ensured in that a data
item is only accessed in the course of a transaction once it has had
a lock applied to it.  If, for instance, it is wished to access a
certain data item during the course of a transaction, and this data
item has just been requested by a different transaction for writing,
the read lock will only be applied once the writing transaction has
released its lock.  Generally speaking, the locks are only released
at the end of a transaction.  These wait times give rise to certain
delays in transaction execution.  This state of affairs is explained
in example 1 on the example of a relational database system.

Individual tuples (lines such as t[1 ] of a table such as Tab 1)
occur as the locked items.

      It is not possible to satisfy the lock requirement for "read
t[3]  &memberof.  Tab2" in Example 1, and so transaction T[3]  must
wait until T[1] is completed.  There are not only overheads for
suspending and re-awakening transactions, but also for the
unsuccessful lock requests.  Analogous delays occur in multiprocessor
systems (multiprocess systems) (one processor (process) must wait for
another).  This leads to a lesser throughput.

      Many applications use only static transactions.  These are
transactions in which the description of the read and write accesses
(Example 1) is already made at compile time of...