Re: Lost invoices (Was: Couple of Oddities...)
Posted in 1992
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL, Server Administration
In article <8872@emory.mathcs.emory.edu>, infmx!obelix!johnl@uunet.UU.NET (Jonathan Leffler) writes:` < stuff deleted...this is my part:> > }If you need to do multiple processing on a queue (say you have two or more > }printers that can handle invoices) then by all means use _interprocess > }communication_ to let all other processes wait on one while that one > }process is performing its search and retrieval (we don't want anything > }disappearing between the time we start our search and the time we try to > }grab the data). > <this is Jonathan's part:> > There is no need to introduce extra IPC facilities into I4GL. You can > perfectly well implement the queue using the table and the database engine, > and application level locking (backed up with database level locking). > > Your queuing algorithm simply inserts a new request into the QUEUE table. > > Your de-queueing algorithm starts a transaction, opens a cursor for update > on the QUEUE table and fetches a row; it then updates the row, marking it > as being processed and recording its PID in the table. It then commits the > transaction. This applies the application-level lock on that invoice, > using the database level locking to ensure that two of the de-queueing > processes do not try to process the same invoice at the same time. When > the dequeuer has finished, it can mark the row as completed, or delete it, > or whatever else is appropriate, as the last steps of the transaction than > processes the invoice. > I concur with this concept. Still, the effort to correctly implement a wait on a request to lock a record should be able to identify the difference between a program/machine glitch and the fact that the record has already been taken by another process. Timers to timeout after some reasonable period of time while waiting on a lock request aren't built in to Informix. Therefore it's not possible to use the Informix tools with 100% certainty and I'm still forced to use a ESQL-C program with multi-processing ( fork a timer routine) to interrupt the wait on a lock request process just in case the whole thing went out to lunch when I made the request. (Mind you, this is theoretical. I haven't actually implemented this to know what I'm talking about, but it seems quite logical.) Now if there were a TIMEOUT function in Informix that would globally affect any command, combined with a flexible ON ERROR function, then I would feel really safe using Informix. The main problem I find with writing applications is that I'm not given the extra time needed to build in error trapping techniques from the start. I'm sure this same mode was beset the authors of 4GL and SQL else all this concern over how to handle errors wouldn't seem to be an after-the-fact catch up. Am I on track with this view? -- --- / . . \\ | - | \\ \\_/ / --- ------------------------------------------------------------------------------ John R. Carter, Sr. Programmer/Analyst - Informix DBA Computer Sciences Corporation jcarter@nas.nasa.gov Numerical Aerodynamic Simulation 415/604-3662 NASA Ames Research Center, Moffett Field, CA 94035-1000 M/S 258-6 ------------------------------------------------------------------------------