LOCKING, Too many concurrent updates on the same record (from mono- to SMP)

Hello, Here follows a porting problem of an application. This appl was running on a mono-processor Unix system and has now to be ported on a SMP Unix system (reason = the volumes to handle in the new environment are much more important). environment = Informix (on Unix), but it doesn't matter the RDBMS that is used. We face the following problem: Let's assume we work on one record (account nr + amount). The appl will update the amount for a specific account nr. Before this update some validation rules are applied which sometimes need to read and even update some of the fields of this record. Ok, as long as those kind of access occur 'at random' on different account nrs, if we use row level locking, the probability to face a locking problem is low. BUT, this appl uses input files that can contain a lot of updates on the same account nr. These update orders are possibly spread in this file. In the mono-processor architecture, each update occured one by one => NO LOCKING problem. In the multi-processor architecture, we need to parallelise this treatment (different TUXEDO processes running in parallel on different processors). Of course we give to each process a piece of the input file. It has also no sense to give to one process all the updates for this same account nr, if a lot of the update orders are for the same record, we would have 1 process running during hours while the others are not used. So => LOCKING PROBLEM. These updates are not at random but are focused on one account nr. Did anybody experienced such a problem while porting a logic from 1 to multiple processors architecture and what is/was your solution. Any help is appreciated. You can answer directly to my e-mail address or reply in the newsgroup. Thanks a lot. Jean-Francois -- ********************************************** * Jean-Francois DENIS * * Siemens Nixdorf Belgium * * Tel: +32-2-536 47 89 * * Fax: +32-2-536 47 80 * * e-mail: jean-francois.denis@s1.bru1.sni.be * **********************************************