Re: Waiting for nonexistant latches

>Every so often (read ``once or twice a day'') our whole database system >locks up, and an investigation of ``tbstat -us'' (users and latches) >invariably shows one or another user waiting for a latch when no latches >are displayed in the latches section of the tbstat output. The problem >persists until a ``tbmode -z'' on the waiting pid clears it. >Additionally, the address of the latch being waited for is always the >same. >Anyone out there got any ideas? >Bill Hails <bill@clic.co.uk> ============================= Bill, This sounds similar to a problem we had on Online 5.0x on an RS6000. However, it didn't "lock up the whole database", just caused seemingly random interferences between users. Since this is a shot in the dark, I'll try to be brief - if I'm on the right track we can follow up. If an update to a record occurs within a transaction, that record is of course locked until a Commit Work. What may not be apparent is that until that transaction is committed, anyone else selecting or updating against that table without reference to a UNIQUE key will find that their SQL call generally fails. Why? Because even for an indexed read, Informix must traverse every index in the database table for a non-unique key, and the one for the transaction-in-progress is inaccessible. And, even if the index in question doesn't match your "where" constraint, Informix can't ignore it or go around it. By the way, this problem exists even in 6.0 and higher, with "key-value" locking instead of the "adjacent key" locking of 5.0x and lower. We had to go to programmatic locking (and avoid syntax like "FOR UPDATE", to keep a transaction as short as possible) to get around this. I have no idea in your particular case why the latch address seems to always be the same. Although, our "informix" database user always seemed to have several rows in use in the tbstat -u table. tbstat -k gives additional info. Good luck! Elliott Friedman Reynolds Metals Company emfriedm@lanmail.rmc.com