Re: [U2] Uniobjects and Record Locking
Post back the cause and fix if you can - I know I'd be interested! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, January 09, 2012 4:11 PM To: U2 Users List Subject: Re: [U2] Uniobjects and Record Locking Done! :-) Thanks, Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/8/2012 7:17 PM *Subject:* Re: [U2] Uniobjects and Record Locking Just open a support case and email the test case... thanks Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Sunday, January 08, 2012 7:46 PM To: U2 Users List Subject: Re: [U2] Uniobjects and Record Locking Wally: I can even re-create this (amazing isn't it?). :-) I'm here all day tomorrow after 10:30am PST. I can call you, if you'd like. Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users Listu2-users@listserver.u2ug.org *Date:* 1/8/2012 1:06 PM *Subject:* Re: [U2] Uniobjects and Record Locking 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. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [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 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 ___ 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
Re: [U2] Uniobjects and Record Locking
Done! :-) Thanks, Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/8/2012 7:17 PM *Subject:* Re: [U2] Uniobjects and Record Locking Just open a support case and email the test case... thanks Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Sunday, January 08, 2012 7:46 PM To: U2 Users List Subject: Re: [U2] Uniobjects and Record Locking Wally: I can even re-create this (amazing isn't it?). :-) I'm here all day tomorrow after 10:30am PST. I can call you, if you'd like. Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users Listu2-users@listserver.u2ug.org *Date:* 1/8/2012 1:06 PM *Subject:* Re: [U2] Uniobjects and Record Locking 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. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [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 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects and Record Locking
It is possible that design base is running a separate locking mechanism that it is caching. The Uniobjects connection involves pooling where multiple user accesses use one UniVerse Login. This is different to a telnet connection with one user per login. If DesignBase cannot identify the process that updates as being the same as the one that locks the record then you could have a problem. You cannot identify who locked the record in a pooling environment as 10 people would have the same user ID, hence it has to be managed by designbase rather than universe. What you are doing is pessimistic locking. With a web based environment and pooling, you should be thinking optimistic locking where you only do locking at the time of update and compare before and after images. If a user locks a record over an internet connection and then loses a connection, then that record can remain locked until an administrator releases it manually, this is why pessimistic locking is avoided in this environment. Regards David Jordan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Sunday, 8 January 2012 10:16 AM 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
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
Re: [U2] Uniobjects and Record Locking
David: Thanks for the input. This has nothing to do with DB, as the message that displays is generated by the update program due to the LOCKED clause being taken, even though there is no record locked. We do a quasi-optimistic locking and only lock records during those few milliseconds where updating occurs. A record is NEVER locked until an update occurs, and since locks release when a program terminates (even a subroutine returns) we shouldn't be having such problems ( i.e. a record is never locked then left alone). This is why I'm thinking it has something to do with Uniobjects. Thanks again, Bill - Original Message - *From:* da...@dacono.com.au *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/8/2012 1:33 AM *Subject:* Re: [U2] Uniobjects and Record Locking It is possible that design base is running a separate locking mechanism that it is caching. The Uniobjects connection involves pooling where multiple user accesses use one UniVerse Login. This is different to a telnet connection with one user per login. If DesignBase cannot identify the process that updates as being the same as the one that locks the record then you could have a problem. You cannot identify who locked the record in a pooling environment as 10 people would have the same user ID, hence it has to be managed by designbase rather than universe. What you are doing is pessimistic locking. With a web based environment and pooling, you should be thinking optimistic locking where you only do locking at the time of update and compare before and after images. If a user locks a record over an internet connection and then loses a connection, then that record can remain locked until an administrator releases it manually, this is why pessimistic locking is avoided in this environment. Regards David Jordan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Sunday, 8 January 2012 10:16 AM 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
Re: [U2] Uniobjects and Record Locking
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
Re: [U2] Uniobjects and Record Locking
Hi Bill Where is the update program. If it is a UniData subroutine, then UniObjects is not in the process. As far as I know UniObjects has no locking process of its own, it uses Unidatas lock table. I have not experienced this problem, this issue like this sounds like a program bug. I would step through the logic carefully, as you may be locking the record twice in 2 different processes as part of the update. Is DB doing an update through its application at the same time you are doing an update. Check the subroutines call logic. Check the security access, does the user have write access. I suspect a process is aborting somewhere that leaves a record locked which is only cleared when the UniObject session is cleared. Have you done a list.readu all after a record locked message has occurred, as you might identify the lock has occurred then. PS did you do LIST.READU or LIST.READU ALL Regards David Jordan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, 9 January 2012 6:34 AM To: U2 Users List Subject: Re: [U2] Uniobjects and Record Locking David: Thanks for the input. This has nothing to do with DB, as the message that displays is generated by the update program due to the LOCKED clause being taken, even though there is no record locked. We do a quasi-optimistic locking and only lock records during those few milliseconds where updating occurs. A record is NEVER locked until an update occurs, and since locks release when a program terminates (even a subroutine returns) we shouldn't be having such problems ( i.e. a record is never locked then left alone). This is why I'm thinking it has something to do with Uniobjects. Thanks again, Bill - Original Message - *From:* da...@dacono.com.au *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/8/2012 1:33 AM *Subject:* Re: [U2] Uniobjects and Record Locking It is possible that design base is running a separate locking mechanism that it is caching. The Uniobjects connection involves pooling where multiple user accesses use one UniVerse Login. This is different to a telnet connection with one user per login. If DesignBase cannot identify the process that updates as being the same as the one that locks the record then you could have a problem. You cannot identify who locked the record in a pooling environment as 10 people would have the same user ID, hence it has to be managed by designbase rather than universe. What you are doing is pessimistic locking. With a web based environment and pooling, you should be thinking optimistic locking where you only do locking at the time of update and compare before and after images. If a user locks a record over an internet connection and then loses a connection, then that record can remain locked until an administrator releases it manually, this is why pessimistic locking is avoided in this environment. Regards David Jordan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Sunday, 8 January 2012 10:16 AM 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
Re: [U2] Uniobjects and Record Locking
Hi Bill You cannot assume the exit of a subroutine clears locks. The way DB works, I suspect that DB has a worker program that calls routines. If that worker program does not stop then locks may not be cleared. When you restart UO you are only then clearing a persistent lock. Also check that the locked message is from the routine you think it is. I don't know your code, I am just passing issues I have seen in the past. Do you have triggers doing an update. It sounds like a lock from a previous step has not cleared. Put a RELEASE statement in the routine before it exits and see if that helps. Regards David Jordan ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects and Record Locking
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. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [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 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects and Record Locking
Wally: I can even re-create this (amazing isn't it?). :-) I'm here all day tomorrow after 10:30am PST. I can call you, if you'd like. Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/8/2012 1:06 PM *Subject:* Re: [U2] Uniobjects and Record Locking 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. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [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 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 ___ 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
Re: [U2] Uniobjects and Record Locking
Just open a support case and email the test case... thanks Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Sunday, January 08, 2012 7:46 PM To: U2 Users List Subject: Re: [U2] Uniobjects and Record Locking Wally: I can even re-create this (amazing isn't it?). :-) I'm here all day tomorrow after 10:30am PST. I can call you, if you'd like. Bill - Original Message - *From:* wterh...@rocketsoftware.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/8/2012 1:06 PM *Subject:* Re: [U2] Uniobjects and Record Locking 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. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [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 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 ___ 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
[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
Re: [U2] Uniobjects and Record Locking
Bill: Your problem might have to do with DesignBais not connecting with the same connection as the first read. I don't know if there is a way to restrict DesignBais to use the same connection. Regards, Doug www.u2logic.com The other Web Developer company On Sat, Jan 7, 2012 at 4:16 PM, Bill Haskett wphask...@advantos.net wrote: 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-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects and Record Locking
Doug: I'm not sure I understand. I know DB does use the same connection for both reads. It's only when I change the connection that it works properly. Thanks, Bill - Original Message - *From:* dave...@gmail.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 1/7/2012 6:18 PM *Subject:* Re: [U2] Uniobjects and Record Locking Bill: Your problem might have to do with DesignBais not connecting with the same connection as the first read. I don't know if there is a way to restrict DesignBais to use the same connection. Regards, Doug www.u2logic.com The other Web Developer company On Sat, Jan 7, 2012 at 4:16 PM, Bill Haskettwphask...@advantos.net wrote: 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-usershttp://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
