Re: Let me be the first

Ok, after talking with my DB2 expert, I understand what your problem is. DB2, and other DB's let you set your lock timeout value at the instance/database level. Informix gives you the same functionality, only at the client level. Informix's defualt lock mode is NOT WAIT. What that means in the scenario you gave is that the the second application would error out as soon as it hit a row the batch process uses. The solution is to take advantage of Informix' SET LOCK MODE syntax. SET LOCK MODE TO WAIT 30; for example tells your applicatoin to try and obtain a lock for 30 second before reporting a locking issue. In normal situations 30 seconds is more than enough time, but on batch intensive boxes, I have seen some apps set their lock mode as high as 120. ----- Original Message ---- From: Lukas Barton <lukas@cnawr.cz> To: informix-list@iiug.org Sent: Monday, September 25, 2006 10:11:17 AM Subject: Re: Let me be the first Obnoxio The Clown wrote: Lukas Barton said: This makes Informix quite unuseable for OLTP in comibination with batch processing (the same time). Shit, you mean I've been doing it wrong for 20 years? And how did you solve the problem I'am facing now: - I have two tables - I use read_commited transactions - User one runs batch process upon them that locks some rows in them for reading (because of locking next and previous record in indexes it also lock some other records) - User two wants to read his records which are locked by user one and must wait until batch process started by user one finishes This works smoothly on Oracle, DB2 (PC and OS400), PostgreSQL, MS SQL, Firebird, Interbase,... where is not so stupid locking implemented.... You don't use transactions? (eg. dirty_reads only). Lukas _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list