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
> 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

Reply via email to