John:
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.
Thanks,
Bill
------------------------------------------------------------------------
----- Original Message -----
*From:* u2g...@btinternet.com
*To:* 'U2 Users List' <u2-users@listserver.u2ug.org>
*Date:* 1/8/2012 8:29 AM
*Subject:* Re: [U2] Uniobjects and Record Locking
If DesignBais is using it's own connection pooling or cacheing mechanism
then it's possible the update request is not being made on the same
UniObjects connection on which the lock was created. The result is exactly
the same as you would expect from two different TELNET sessions - one locks
the other. If you force a release of the lock as root/administrator on the
server and the update proceeds then you have the cause and need to change
either DesignBais or the methodology the application uses. If you release
the lock and the update still can't proceed then DesignBais is probably
using an internal locking mechanism that has some issues.
As we all know, you can only update or release a locked record on the same
session which holds the lock.
Also a pointer - if you are using UniObjects with U2 Connection Pooling,
then the same can apply the moment you have two server processes on the same
connection pool. Each request made to a connection pool could be serviced by
ANY process assigned to that pool - not necessarily the last one you
happened to get assigned to your last request. (After all - that's the whole
point of Connection Pooling - POOLING being the operative word. This is
quite different to UO without Connection Pooling where the client to server
link is one-to-one. With Connection Pooling it is many-to-many.
The locking mechanism DesignBais is using needs to be re-thought if either
of these applies. You should be using optimistic locking for scalability in
any case,
Regards
JayJay
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: 07 January 2012 23:16
To: U2 Mail List
Cc: DesignBais Support
Subject: [U2] Uniobjects and Record Locking
I'm using DesignBais and have run into an unusual problem. When I display
some data on a web form the dbms is contacted through UO and the returned
data is displayed. When I click on the [Save] button the same UO connection
is used to contact the dbms and run whatever program is required to update
the record.
In the called update program, the record is read and locked. If it's
already locked the program terminates and a message is returned informing
the user the record is locked (try again). If it's not locked the record is
updated and, of course, the program terminates in the same manner.
Problem: if I edit the record via UniData's AE editor (LIST.READU shows a
record lock) and try to update the record via the DesignBais form, the
LOCKED clause is taken. This is good. However, after I release the record
via the AE editor (LIST.READU now shows nothing locked), then click on the
[Save] button, the LOCKED clause is still taken, even though no record is
locked! If I kill the UO connection, DesignBais will make another UO
connection and all works fine.
So, it appears a UO connection won't release a lock under whatever
circumstances I've happened to stumble upon. Any ideas what causes this and
how to "work-around" the problem?
Thanks,
Bill Haskett
Advantos Systems, Inc.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
