My whole point in the original posting is, that many application programmers do not even think about correct locking sequences, transactions and deadlock avoidance. All they do is make sure that the record is locked while updating. This is not enough! As part of a "Good Programming Practice" I would recommend to
Put your files in a sequence and always lock them in that sequence! In my example that would mean: Always lock the header before you lock the detail. Otherwise you are in trouble with deadlocks and most probably you will not even realize it when testing. I give you another example of how using transaction processing makes things even worse: - Program one writes a record to a journal, then updates a balance in another file. - Program two first updates the balance, then writes the journal. So far, everything is fine. As locks are released immediately, no danger of deadlocks. Then you introduce transaction processing and put the step of writing the journal and updating the balance into one transaction. Unfortunately locks are not released within a transaction until the whole transaction is finished (committed). So what happens is: - Program one writes to the journal. The lock is kept even after the write, because you are in a transaction. - Program two writes to the balance file. The lock is also kept because of the transaction. - Program one tries to obtain the lock on the balance file. - Program two tries to obtain the lock on the journal. - Deadlock! Conclusion: If you put your files into a sequence and only lock (update) them in that sequence, you do not even need to think about all this. You never get in any troubles, even when making your application transactional. So this should be worth thinking about when training new programmers for good coding style. -----Urspr|ngliche Nachricht----- Von: David Tod Sigafoos [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 29. September 2005 17:53 An: Serguei Betreff: Re[2]: AW: [U2] Good Programming Practice Question......... Serguei, Thursday, September 29, 2005, 8:04:07 AM, you wrote: S> There is no reason to lock details if the header is locked (you would S> not want two users to modify the same invoice). So the correct S> procedure is not to lock details at all. '... So the correct procedure ...' <G> What problem does this cause? IF the locks are placed and removed correctly there is no problem. I would agree that it is easier to simply lock the header but only if you can guarantee that this will IN ALL SITUATIONS handle the entire set. Should be .. could be .. maybe .. Sometimes, as a consultant, I might do this (belt and suspenders) because of the state of the code and programming style that the 'employees' (monkeys) have exibited in the system does not give me any confidence that they will correctly respect lock 'sets' that way. dsig ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
