Browse Prior Art Database

Locking in a Binary Relational Data Data Base

IP.com Disclosure Number: IPCOM000045331D
Original Publication Date: 1983-Mar-01
Included in the Prior Art Database: 2005-Feb-06
Document File: 2 page(s) / 13K

Publishing Venue

IBM

Related People

Pullin, DJ: AUTHOR [+4]

Abstract

This article describes a deadlock-free mechanism for locking the collection of triples required to assemble and disassemble a record in situations where many users of application programs may have concurrent access to the same triples through different routes.

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

Page 1 of 2

Locking in a Binary Relational Data Data Base

This article describes a deadlock-free mechanism for locking the collection of triples required to assemble and disassemble a record in situations where many users of application programs may have concurrent access to the same triples through different routes.

For any given record transmitted across the application program interface, it is possible to identify a set of triples which must be accessed to form the record. Certain record requests (e.g., read for up-date) require that it is possible to retrieve the identical record at a later time. Thus, it is necessary to lock the triples forming the accessed record. One method would be to lock every triple accessed in forming each record: however, this would involve a high overhead since the number of locks which must be acquired is proportional to the number of fields in the record.

In the mechanism described below a superset of the necessary triples is held by the accessing application, while only a subset of the necessary triples is explicitly locked.

A triple is defined in general by the form (x, y, z) where x, y, and z are identifiers of database elements which name entities in the real world. A particular use of triples is in representing record structures, in which each triple takes the form (key, relationship name, attribute field). In general, a record may be considered to have more than one such key field.

In order to lock such record it is necessary to lock a collection of triples which may be factored into a number of subcollections. Within each subcollection, all triples have a common key field.

A mechanism is proposed which enables e...