UniData record locks are tied to a file variable. So if a file is opened in
named common, a lock could persist after a subroutine exits. Of course, it
would show up in LIST.READU...
The behavior Bill describes doesn't make sense to me. Would love to see a small
test case demonstrating what he describes.
U2 Support Architect
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Sunday, January 08, 2012 12:48 PM
To: U2 Users List
Subject: Re: [U2] Uniobjects and Record Locking
As a note, we've been programming in web paradigms for many years, and we
mostly understand the difference between non-persistent web connections and
persistent telnet connections.
None of our activities does anything except gather data and submit to UO for
almost instantaneous results, whereupon the results is returned to the web.
These are all momentary connections and no LOCKING occurs except within the
context of a momentary update. So, the user calls the web server, a UO
connection is either reused or created to connect to the dbms, a subroutine is
run and ends (which, of course, should release all locks within the subroutine
(unless doing something like a WRITEU which we never do - we're old-school in
that regard), the the web call is closed and data returned by the UO connection
is returned to the user in another web page, and the web connection is closed.
I think what's important to note is a "LIST.READU ALL" shows the lock when AE
has the record edited and the BASIC LOCKED clause is taken on a momentary UO
connection. When AE exits the record "LIST.READU ALL" no longer shows any
record locks but the BASIC LOCKED clause on a subsequent UO connection is still
taken as though the record is locked only if the UO connection where the lock
occured is reused. If a new UO connection is used (due to timeouts or manually
killing the original UO
connection) the BASIC LOCKED clause is __NOT__ taken.
U2-Users mailing list