RE: SELECT FOR UPDATE

A 'document' may consist of several records from several tables, a
relationship the DBMS doesn't understand.  It also introduces alot of
complexity.  You may need a way to expire locks after a certain amount of
time, or allow some users to override other users' locks.

In a system I'm working on, I have a facility for both, and the expiration
code works in two steps.  At creation, the lock is 'mandatory' and can only
be overridden by an admin user.  After a day of inactivity against the lock,
it becomes 'advisory', meaning that anyone can override it, but if it is not
overidden it remains valid for the owner for one week, after which time it
is removed altogether.

Stuff like that is, IMHO, far beyond the scope of an SQL server.

Glen Parker
glenebob@nwlink.com


> I prefer Jan's solution: on first attempt to change, acquire a user-level
> lock by creating a lock record; if you can't get the lock, don't allow
> any change.
>
> However, it would be convenient if the database would do this for me.  I
> still don't understand why people think it undesirable for it to
> do so, since
> it is a problem universal to multi-user databases and the effort is
> therefore more economically spent at the database rather than at the
> application level.