Technical data

you specify CONCURRENT or PROTECTED modes, the DBCS initiates locking
at the record level.
Individual records are locked as they are retrieved by the run unit. The degree
of locking depends on the specific DML command used. For example, if your run
unit executes a FETCH or FIND statement, the DBCS sets a read-only record
lock, allowing other run units to read, but not update, the records. This lock is
also set if your run unit assigns the database key associated with the record to a
keeplist with the KEEP verb. (Note if you use FETCH or FIND FOR UPDATE, a
no-read lock is placed on the specified record.)
As a record is retrieved, the lock is held at this level until there are no more
currency indicators pointing to the record. If the program assigns a record to
a keeplist, the lock is held by your run unit until it frees the record from the
keeplist with a FREE statement. However, if a currency indicator points to a
record whose database key is also in a keeplist, then a FREE statement to that
keeplist entry still leaves the read-only lock active for that record. Similarly, if
the same database key is in several keeplists, then freeing it from one keeplist
does not release the other read-only locks.
However, the DBCS grants a no-read access lock if your run unit specifies a DML
update verb, such as STORE, CONNECT, or MODIFY. Your run unit retains the
lock on this record until the change is committed to the database by the DML
COMMIT verb or the change is terminated or canceled by ROLLBACK.
The Run-Time System notifies the DBCS each time a run unit requests a locked
record, thus keeping track of which records are locked and who is waiting for
which records. This logging helps the DBCS determine whether a conflict exists,
such as multiple run units requesting, but not being allowed, to access or change
the same record. For more information on record locking, refer to the Oracle
CODASYL DBMS documentation on database design and programming.
6.2 COMMIT and ROLLBACK
When you are in CONCURRENT UPDATE mode, any changes made to a record
lock the record and prevent its access by other run units. For example, if a
program updates 200 customer records in one transaction, the 200 customer
records are unavailable to other run units. To minimize lockout, use the
COMMIT statement as often as possible.
The COMMIT statement makes permanent all changes made to the database,
frees all locks, and nulls all currencies. It also establishes a quiet point for your
run unit.
The RETAINING clause can be used with the COMMIT statement. COMMIT
RETAINING does not empty keeplists; retains all currency indicators; does not
release realm locks; demotes no-read locks to read-only locks; then releases locks
for all records except those in currency indicators or keeplists and makes visible
any changes made to the database.
To use COMMIT properly, you need to know about application systems. For
example, you might want to execute a COMMIT each time you accomplish a
logical unit of work. Or, if you were updating groups of interdependent records
like those in Figure 6–1, you would execute a COMMIT only after updating a
record group.
DML Programming—Tips and Techniques 6–3