| Locking considerations are one of the key element of success in the
design of multi-users MODIFY applications. I wrote numerous internal
notes, while at IBI, and some of them must be available from IBI's
Hotline in New-York.
However these are some general indications and guidelines :
A) Read-Interface {TABLE} : opens a read-only transaction (if Snapshot
is enabled) for each request and each database accessed (in the
case of multiple tables, be carefull here with using DDNAME)
B) Write Interface (Not use within Digital) {MODIFY}
(Up to FOCUS version 6.2) opens a read-write transaction. The
transaction stays open until explicitly commited or rolledback
or until then end of the MODIFY.
Note : RdB Read-Write transaction have a degree 3 of consistency,
also known as repeatitive read, e.g. if reading twice the same
record its value is constant, which also means the record is
READ LOCKED for the duration of the transaction preventing someone
else from updating it.
Note : When doing a commit answer sets are being flush, causing
FOCUS to restart requests (This may have undesirable effects on
NEXT processing)
The golden rule of TP shall never be forgotten : Do terminal I/O
outside the transaction mode, so you guaranty that a user sitting
in front of its terminal doesn't hold half of the database locked.
Note : Access shall be done through index, otherwise RdB needs
to read (lock) all the records before finding the one you want.
Therefore MODIFY procedures shall commit changes as soon as
locks are not needed any more. Also remember that read operation
(MATCH or NEXT) will place read-lock preventing users from
updating these records.
However be a tradeoff has to be found, if NEXT answer sets are
open and haven't been exhausted because COMMIT will flush them
requiring from FOCUS to do the read again.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Version FOCUS 6.2, improves locking to a great extend by opening
two simultenaous transactions :
one read-only for read operations (MATCH NEXT FIND)
on read-write for write operations (Internal rematch, UPDATE DELETE
INCLUDE)
-------------------------------------------------------------------------------
Because this is critical, monitoring of the transaction and locking
activity shall be done during the design phase. (You might have bad
surprise)
RDMS$DEBUG_FLAGS B
and
FSTRACE facility in focus are some of the tools to do it.
Hope this wasn't to much confusing but the subject is complex, and indeed
important. Don't hesitate to seek advice from IBI on the subject.
Jean-Claude
|