RE: Row locks in DB2/400 UDB

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: rob@xxxxxxxxx
> 
> Yes it can, but with a cursor.  You see, RPG has no equivalent of
SQL's
> single UPDATE statement.

Actually, SQL has no equivalent to the basic ISAM concept of
"read-with-lock".  The atomic lock is a fundamental requirement for
database processing in a multitasking environment, since it acts as a
database-level semaphore.  Without it, you need process synchronization
at the application level, and that can get pretty nasty.

SQL until recently ignored locking for the most part and rolled it all
into the commitment control basket, which is a little bit less pretty.
This is a simple reflection of the fact that SQL is set-based, while
ISAM is record based.

SQL is catching up.  Scrollable, updatable cursors provide many of the
capabilities of the basic ISAM view, including record locking, but
there's still the issue of positioning one of those views by key, and
performing the basic read-next-equal functions required for normal
record-at-a-time processing.  Also, I'm not sure how SQL decides whether
to use record locking or commitment control, and the vendors are still
shaking out the details.  For example, Oracle didn't have such cursors
until version 9i.

However, I don't worry about those things.  If I want process a group of
records one at a time, I use native I/O.  If I want to process them all
at once, I use SQL.  In my environment, strict adherence to either is a
waste of CPU cycles (not to mention programmer cycles).

Joe