Browse Prior Art Database

Locking Technique in a Relational Data Base: Locking on Intents

IP.com Disclosure Number: IPCOM000084708D
Original Publication Date: 1975-Dec-01
Included in the Prior Art Database: 2005-Mar-02
Document File: 3 page(s) / 16K

Publishing Venue

IBM

Related People

Eswaran, KP: AUTHOR

Abstract

This description relates to relational data base management and, more particularly, to managing the conflict between two or more programs seeking to extract and modify the "same information in a file". In relational data bases, files also consist of relations among defined terms.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 3

Locking Technique in a Relational Data Base: Locking on Intents

This description relates to relational data base management and, more particularly, to managing the conflict between two or more programs seeking to extract and modify the "same information in a file". In relational data bases, files also consist of relations among defined terms.

Locking in a data base is different from locking in Operating Systems environment in the following ways: (1) The number of resources (specified by tuples or fields in the tuples) is astronomical, and (2) The resources are not necessarily named physical objects. That is, the resources are specified by associative addressing. For example, in Operation Systems, a process may lock a particular tape unit whereas a transaction running in a data base environment may want to lock a set of tuples with, say, the value of a specific column = `San Jose'. The transaction does not care what exactly are the tuples that satisfy the criteria.

Once such a set is locked by a transaction, no other transaction should either delete a tuple from this set or add a tuple to this set (such tuples are called "phantom" tuples). These problems are further discussed in "On the Notions of Consistency and Predicate Locks in a Data Base System" by K. Eswaran, J. Gray, R. Larie and I. Traiger, RJ 1487, December 30, 1974.

This description provides a solution for locking that, (1) solves the problems of phantoms, and (2) provides maximum concurrency when locking is done without reading any part of the data base.

It is assured that every transaction in the data base system specifies an "intent". An intent is essentially a subrelation and operation on the subrelation:
(1) A set of rows of a relation(s) which may be of interest, specified by a "predicate"; (2) A set of (columns) domains (in those interested rows) which the transaction may read, specified as "argument domains"; and (3) A set of domains (in those interested rows) which the transaction may change, specified as "change domains". Specifying these intents lets the system lock only the subrelations that may be needed by the transaction, i.e., "granularity of locking is the finest".

(1.a) Predicate: A predicate indicates the rows of a relation(s) that a transaction may be interested in. It is in disjunctive normal form (disjunction of one or more clauses). Each clause has one or more terms in conjunction. Each term is a predicate whose arguments are a domain name and one or more constants (values).

(Image Omitted)

Example 1: Suppose that a transaction is interested in rows of the EMP relation having values of the domain DEPT equal to K50 and values of the domain SALARY between 17 and 25K, and rows of PERSONAL having values of the domain AGE less than 65. Then the predicate is:. [(EMP - DEPT - K50) (17K </- EMP . SAL </- 25K)] v [(PERSONAL AGE < 65)] where means "boolean AND", v means boolean OR. (1.b) Predicate Domains: This is a set of domains

1

Page 2 of 3

which are exp...