SE Help !!!!!

> We are running Informix 4gl version 4.10.UE2 on the SE engine 5.00.UC2 > > The hardware is a Sequent S81 Dynix/ptx 2.0.3 > > The problem: > > We believe we are having a serious problem with database locking. We have > looked at the standard disk contention issues but have not been able to > ascertain any good information on who has what locked. I miss Online :-( > > Is there any way short of writing very extensive logging functions ( we have > lots of code ), to determine who has a table/row locked in SE ? Informix > says "no" but im not always convinced by that. > > Some users are being locked for 30+ minutes. > > Please help. You can log as much as you can stand to read, or until the disk fills up. We use calls to a "trace" function we wrote that records who is doing what, where, when. I think it's a 4gl function, but it may be written in c. Either one would be pretty easy to do. This would involve fairly extensive changes to your application code, in proportion to the amount of information you wish to store. Or, you can write your own locking scheme, using a "locks" table of your own definition. We have an application which does that. It checks the table for who is holding a lock, and the check yields also where the "locker" is physically located and what he intends to do. The cost of such functionality is that you have to do all the work yourself, dealing with dying processes, orphan and bastard locks, terms like "dirty read" and "exclusive" and "intent". It is a real hassle. OTOH, Informix has already done a great deal of work to do that for you, and there is no good reason why their system can't be made to work. For example, are you using row or page level locking? Are dirty reads being used, are they even appropriate? Are you familiar with the tbstat tools for determining who has locks and on what? (They suck, and I'm not certain they are in SE, but I think so...) Tbstat can give you a lot of clues about who is waiting on whom for locks. Does your application lock the table/row for an un-necessarily long time? It should be written so as to create a lock only momentarily, and NOT to hold it open for the duration of time it takes the user to fill his screen and indicate that he wants to save changes. Do you use waits in your code in the event of a lock? For how long? Boy, that turned into a long-winded tirade. Hope it helps, __________________________________________________________________ | Clem Akins Standard Disclaimers Apply | |Reynolds Metals Co, Alloys Plant "Climb High, Cave Deep!" | | Muscle Shoals, Alabama USA cwakins@leia.alloys.rmc.com | |________________________________________________________________|