PROGRESS 8.3A database

I am using PROGRESS 8.3A on a Sun machine running Solaris 2.5.1. Sometimes I get the following entries in the PROMON's "Record Locking Table" option.

Record Locking Table:
Usr Name     Chain #    Rec-id Lock Flags
260 UOPDMKIA REC  2285  13464166 SHR
201          REC  2606  80900451 EXCL U  Q
245          REC  2606  80900451 EXCL U  Q
233 B5ZAXIPX REC  2607  84990306 SHR
232 B5CSLIPX REC  2705  73007265 EXCL

Whenever entries with Flag "U Q" appears, my application users will not be able to log in to the database. Usually, I have to kill these users to solve the problem.

Can anyone tell me what does the flag "U Q" means, what causes it & how to solve this problem ?

Thanks.
jackyleeeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

hakanilsCommented:
The U flag means that the user has requested a lock upgrade from share to exclusive but is waiting for another process that holds a conflicting lock.

The Q flag represents a queued request for a lock already held by another process.

You have locking problems. Probably you got some kind of deadlock (deadly embrace). If two users have read the same record with share lock. Both users wants to update the record and Progress automaticly upgrades the lock to exclusive then you can get problems.

When I have locking problems I think it's easier to see it in the User Control meny option in Progress Monitor. Look at the Wait and column there. The wait column tells what it is waiting for. I think you can se Monitor information in the System Administration Reference book. This was true for version 7, but I can't tell you for version 8 though I haven't used it.

In multiuser environments I strongly recommend you NOT to use share locking. You almost always know if you are going to update the record or not. If you are going to update the record then read it with exclusive lock otherwise read it with no-lock.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jackyleeeAuthor Commented:
Is there any other way to solve this problem other than changing my application programs ?
0
hakanilsCommented:
You don't have the source code or what?

If you have the source code you have to find the statement that reads records and share there. Not the whole application.

I have no solution for you. The only flag a know that is changing the locking behavior is the -NL flag or No-Lock flag. It changes the default locking from share-lock to no-lock. But I think there is no hope for your problem. You can always try, but probably you get an error message when there is an update in the database.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Databases

From novice to tech pro — start learning today.