Download GemStone/S Programming Guide

Controlling Concurrent Access With Locks
GemStone Programming Guide
To prevent another user from obtaining possibly inaccurate data, you must acquire
an exclusive lock on every employee.
GemStone’s exclusive locks correspond to what traditional data management
systems call exclusive locks, or sometimes just write locks. By contrast,
GemStone’s write locks are not exclusive in the conventional sense, because other
sessions can read a write-locked object optimistically (that is, without holding a
lock) and still commit.
Acquiring Locks
The kernel class System is the receiver of all lock requests. The following
statements request one lock of each kind:
Example 6.3
System readLock: SharedDictionary.
System writeLock: myEmployees.
System exclusiveLock: someMoreData.
When locks are granted, these messages return System.
Commits and aborts do not necessarily release locks, although locks can be set up
so that they will do so. Unless you specify otherwise, once you acquire a lock, it
remains in place until you log out or remove it explicitly. (Subsequent sections
explain how to remove locks.) Variants of these messages for locking collections of
objects en masse are described in the section “Locking Collections Of Objects
Efficiently” on page 6-19.
When a lock is requested, GemStone grants it unless one of the following
conditions is true:
• You do not have suitable authorization. Read locks require read authorization;
write locks and exclusive locks require write authorization.
• The object is an instance of SmallInteger, Boolean, Character, or nil. Trying to
lock these special, atomic objects is meaningless.
• The object is already locked in an incompatible way by another session
(remember, only read locks can be shared).
6-16
GemStone Systems, Inc.
December 2001