General concurrency question

We have a simple record locking schema for concurrency control in a critical code section: 1) WAIT UNTIL LOCK RECORD NOTFOUND 2) INSERT LOCK RECORD .. 3) INSERT ROW .. 4) DELETE ROW .. 5) DELETE LOCK RECORD The step 1 seems to work and sets users to wait their turn (waiting the other user finish the step 5). The LOCK RECORD has an unique index and it prevents two simultaneous users in critical section (steps 3 & 4). Anyway I suspect that in rare situations the user A who is leaving the critical section DOES NOT GET it's information updated BEFORE next user (let's say user B) gets in. Is there any possibility that user B can execute step 3 BEFORE user A has it's step 4 updated???? We use IDS 7.31.UC5 and compiled 4GL 7.20.UD4. Database does not have transaction. Thanks in advance from a very confused user..

Its unclear why you need to use an artificial locking scheme when Informix has an excellent built-in locking mechanism. What's happening in Step 3 and 4 that needs to be done one user at a time? Even if you did have such a neccessity, your program could be coded as follows : BEGIN WORK; SET LOCK MODE TO WAIT; LOCK TABLE <table> IN EXCLUSIVE MODE; INSERT ... DELETE ... COMMIT WORK; Rudy "Pentti Tietäväinen" wrote: > We have a simple record locking schema for concurrency control in a critical > code section: > > 1) WAIT UNTIL LOCK RECORD NOTFOUND > 2) INSERT LOCK RECORD > .. > 3) INSERT ROW > .. > 4) DELETE ROW > .. > 5) DELETE LOCK RECORD > > The step 1 seems to work and sets users to wait their turn (waiting the > other user finish the step 5). > The LOCK RECORD has an unique index and it prevents two simultaneous users > in critical section (steps 3 & 4). > Anyway I suspect that in rare situations the user A who is leaving the > critical section DOES NOT GET it's information updated BEFORE next user > (let's say user B) gets in. Is there any possibility that user B can > execute step 3 BEFORE user A has it's step 4 updated???? > > We use IDS 7.31.UC5 and compiled 4GL 7.20.UD4. Database does not have > transaction. > > Thanks in advance from a very confused user..

Hello Rudy Yes it's possible to use the mechanism SET LOCK MODE TO WAIT; LOCK TABLE <table> IN EXCLUSIVE MODE; Anyway I don't see the solution here if the database is not using transactions. Pentti Rudy Fernandes <rferdy@americasm01.nt.com> wrote in message news:3961EC4F.D395616E@americasm01.nt.com... Its unclear why you need to use an artificial locking scheme when Informix has an excellent built-in locking mechanism. What's happening in Step 3 and 4 that needs to be done one user at a time? Even if you did have such a neccessity, your program could be coded as follows : BEGIN WORK; SET LOCK MODE TO WAIT; LOCK TABLE <table> IN EXCLUSIVE MODE; INSERT ... DELETE ... COMMIT WORK; Rudy "Pentti Tiet'v'inen" wrote: > We have a simple record locking schema for concurrency control in a critical > code section: > > 1) WAIT UNTIL LOCK RECORD NOTFOUND > 2) INSERT LOCK RECORD > .. > 3) INSERT ROW > .. > 4) DELETE ROW > .. > 5) DELETE LOCK RECORD > > The step 1 seems to work and sets users to wait their turn (waiting the > other user finish the step 5). > The LOCK RECORD has an unique index and it prevents two simultaneous users > in critical section (steps 3 & 4). > Anyway I suspect that in rare situations the user A who is leaving the > critical section DOES NOT GET it's information updated BEFORE next user > (let's say user B) gets in. Is there any possibility that user B can > execute step 3 BEFORE user A has it's step 4 updated???? > > We use IDS 7.31.UC5 and compiled 4GL 7.20.UD4. Database does not have > transaction. > > Thanks in advance from a very confused user..

"Pentti Tietäväinen" wrote: > Hello Rudy > Yes it's possible to use the mechanism SET LOCK MODE TO WAIT; LOCK TABLE > <table> IN EXCLUSIVE MODE; > Anyway I don't see the solution here if the database is not using > transactions. I guess I missed the bit about the database not having transactions. You actually could duplicate that functionality in a database without transactions by using the following statements : SET LOCK MODE TO WAIT; LOCK TABLE <table> IN EXCLUSIVE MODE; INSERT ... DELETE ... UNLOCK TABLE <table>; Still curious, though. What's the case for having a database, that needs concurrency control, not having logging turned on? Rudy

Hello, The software is evolved from days when transaction logging was not implemented! It's not only to set up the "logging mode", you have to change code to handle cursors, etc.. Anyway the base question remains. Is it quaranteed that the user A get's it DELETE done before user B's INSERT? Pentti Rudy Fernandes <rferdy@americasm01.nt.com> wrote in message news:39632168.A9CE5D0B@americasm01.nt.com... "Pentti Tiet'v'inen" wrote: > Hello Rudy > Yes it's possible to use the mechanism SET LOCK MODE TO WAIT; LOCK TABLE > <table> IN EXCLUSIVE MODE; > Anyway I don't see the solution here if the database is not using > transactions. I guess I missed the bit about the database not having transactions. You actually could duplicate that functionality in a database without transactions by using the following statements : SET LOCK MODE TO WAIT; LOCK TABLE <table> IN EXCLUSIVE MODE; INSERT ... DELETE ... UNLOCK TABLE <table>; Still curious, though. What's the case for having a database, that needs concurrency control, not having logging turned on? Rudy