Re: Lost invoices (Was: Couple of Oddities...)

}From: uunet!nas.nasa.gov!jcarter (John R. Carter Sr.) }Subject: Re: Lost invoices (Was: Couple of Oddities...) }Date: 6 May 92 18:00:42 GMT }X-Informix-List-Id: <news.1188> } }In article <8849@emory.mathcs.emory.edu> you write: }|> I'm observing some strange things happening with an invoicing process }|> that we're using at a client. The operator fires off an invoice program }|> that runs in the background and inevitably spools the invoice to the }|> printer. }|> }|> ... }The way I would handle this is to QUEUE the invoices and let one process }handle the data in the queue. The same would apply anytime you use a LOG }file or a LOG record. }A database QUEUE is a table that you add data to that is to be processed, }much like lp or lpr processes print requests. Multiple database }application processes can add records to this table at will but only one }process removes and processes data from this table. This means a separate }running progr am for that process which is not tied to the application that }puts data into the queue. If the data in the queue table is to be }processed by priority , then one field in the table can have a priority }function, like: } "do all A's, then B's", or } "search for smallest value". }The queue handler repeats its search instruction after processing each }record. Fine: no problems so far. }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). 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. }Many thanks to Covalent for this one. (I hope they didn't copyright this }technique. My appologies if they did.) If they did copyright it, that does not stop someone else re-inventing it, or re-using the idea, at least, not in the UK. Copyright protects the particular form in which the idea is expressed, not the idea itself. If they'd patented it, that would be a different matter, though I don't think that people in the UK can copyright algorithms, nor patent them. Yours, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>