LOCK MODE WAIT doesn't seem to work in SE

I was surprised to find that, under SE, if a table is locked and I attempt to read it having executed a SET LOCK MODE TO WAIT, the read aborts on error -242/ -113, rather than waiting for the lock to clear. I've demonstrated this using two sessions of dbaccess, both with versions 5 and 7. (It all worked as expected when I tried it under my IDS system.) It is giving serious problems to a client of mine whose application seems to acquire numerous table-level locks of short duration. Programs are bombing out on lock errors all over the place and I cannot work round the problem with SET LOCK MODE. The errors start to come thick and fast when more than 80 users log on. Can anyone shed some light on what is going on please? -Andy Kent- Bristol, England.

Andy Kent wrote: > > I was surprised to find that, under SE, if a table is locked and I attempt > to read it having executed a SET LOCK MODE TO WAIT, the read aborts on > error -242/ -113, rather than waiting for the lock to clear. I've > demonstrated this using two sessions of dbaccess, both with versions 5 > and 7. (It all worked as expected when I tried it under my IDS system.) > > It is giving serious problems to a client of mine whose application seems > to acquire numerous table-level locks of short duration. Programs are > bombing out on lock errors all over the place and I cannot work round the > problem with SET LOCK MODE. The errors start to come thick and fast when > more than 80 users log on. > > Can anyone shed some light on what is going on please? Are you trying to use a timeout, as in SET LOCK MODE TO WAIT 10? This is IDS only functionality. Since SE uses OS level locks which do not have a timeout feature, you either block on them or you do not, this feature is no-op when running against SE engines. You CAN successfully use the unconditional SET LOCK MODE TO WAIT; without a timeout and use signals and the sqlbreak() function in your code to emulate this behavior if you need the timeout. Since you say the locks are short lived I'd just code without a timeout. There is a way to detect at runtime whether you are running against an IDS or SE database so you can make the code conditional at runtime, I just cannot remember what it is. Anyone else? Alternatively you could just use a #define to make the code conditional at compile time and have different executables for SE and IDS. Art S. Kagel

Andy Kent wrote: > I was surprised to find that, under SE, if a table is locked and I attempt > to read it having executed a SET LOCK MODE TO WAIT, the read aborts on > error -242/ -113, rather than waiting for the lock to clear. I've > demonstrated this using two sessions of dbaccess, both with versions 5 > and 7. (It all worked as expected when I tried it under my IDS system.) > > It is giving serious problems to a client of mine whose application seems > to acquire numerous table-level locks of short duration. Programs are > bombing out on lock errors all over the place and I cannot work round the > problem with SET LOCK MODE. The errors start to come thick and fast when > more than 80 users log on. > > Can anyone shed some light on what is going on please? > > -Andy Kent- > Bristol, England. The SET LOCK MODE TO WAIT will wait when a RECORD is locked, but you will get that error if the TABLE is locked. That's what I've from SE, i dont know about the other engines. Some work in your customer's application might need to be done, either by a loop or not using table lock that much.. Luc Chatelain