Locking plan for 6.5

Hi Folks of Concern,

    I noticed that 6.5 is planned to have row-level locking; and
basically allowing all readers and writers to read. Is there going to
be any way to implement pessimistic/exclusive locking? I have to deal
with many data entry people who have little if any correct notion of
what they are actually doing. Point is, when someone starts editing a
record manually I want to be able to lock it upon commencement of
edits, not upon the actual update. This, to prevent contention on
updating, which would not be acceptable.

    One scenario I have is with Progress (DBMS), in which I can
bypass locks (read-only) if I choose. But, for data entry, I need to
determine if someone else is currently editing the record that I want
to edit. Progress remedies these situations with exclusive locks
which can also inform of the userid of the locker. Most importantly,
is the inability to BEGIN edits on a record that is already being
edited, which prevents all kinds of management problems associated
with educating, often times, _temporary_ data entry people about
contention problems of this sort. They simply wait, write down
information, or in the case of Progress, even call the operator who
is locking them out. I certainly don't want them forcing updates or
spending time determining whose data is most current, or whether
they've changed the same fields, or...

    It's basically like using a mutex. The user sees the latest version
(or WAITS for it), and makes decisions whether to change data based
on that.

The question would best be put as:
    Will I be able to prevent others from attempting to manually edit
a record that is already being edited? (This, as a built-in feature
of the DBMS)

Thanks,
Bill