Re: Problems with locks and committed read

Hi ! thx for the answer. > You say the[....] transaction and have to > expicily issue a commit or a rollback to free the locks. That the way i want the whole thing to work. The application is already coded, it's just an adaptation to informix. I do not want to wirte begin and end section each time i have a query > If this is not the problem... > > what do you want to happen if a row is locked? > > You don't want to read the phantom row, but you don't want the app > stop when it encounters the lock? Yes that's absolutely what i need. Session1: insert into test_table (colA) values ('valuesA')/* I do not commit */ Session 2: select * from test_table/* I want to all the rows in test_table excepted the 'valuesA' newly inserted */ Session 1: rollback / commit At this time if i rollbak => data are not waiting to be processed in session 2 process so not phantom teatement will occur If i commit, it will wait the next read of the table to be processed > Are these short transactions? If so, how about "set lock mode to > wait". the select will then wait till the lock is released (which > should occur when you run the commit work or rollback work > statements). No they can be long., or almost use concurrency (they try to access the same table at nearly the same times) i mean the definition on concurrency. An exemple with 2 processes ( 1 and 2 ) 1) when starting it insert data in some table and wait for answer for the second task before committing transaction. 2) it initialize data in memory ( by reading table where data has been inserted by 1) so : 2 can wait for ages :) and so goes 1 I have thought of using dirty read , but it create with a high level i think , phantom data.... I'm thinking of using dirty read and test lock at the same time....