Are you talking about a specific application here or in general? ----- Original Message ----- From: "Serguei" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Thursday, September 29, 2005 10:04 AM Subject: Re: AW: [U2] Good Programming Practice Question.........
There is no reason to lock details if the header is locked (you would not want two users to modify the same invoice). So the correct procedure is not to lock details at all. ----- Original Message ----- From: "Dave S" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Thursday, September 29, 2005 2:51 PM Subject: Re: AW: [U2] Good Programming Practice Question......... > - Another part of the application selects a record > > from the "Invoice Detail" file. It locks it for > > update and then locks the associated "Order Header" > > entry e.g. to adjust summaries. > > You could lock the header file first, and then lock > the detail file to avoid this "deadlock". > > --- Ewinger Klaus <[EMAIL PROTECTED]> wrote: > > > When talking about lock management: > > > > Define a sequence in which you are updating the > > files of your application. If you do not take care > > of the sequence of your locks, you will most > > probably run into deadlocks. This is especially true > > when using transaction processing, as transactions > > increase the lifetime of locks. > > > > A typical scenario that is often seen in > > applications which is a source for deadlocks: > > > > - There are two files: "Invoice Header" and "Invoice > > Detail" > > - One part of the application updates an invoice > > from an entry screen. It locks the "Invoice Header" > > record first and the "Invoice Detail" record then. > > - Another part of the application selects a record > > from the "Invoice Detail" file. It locks it for > > update and then locks the associated "Order Header" > > entry e.g. to adjust summaries. > > - Bang! You've got your deadlock situation. > > > > > > -----Urspr|ngliche Nachricht----- > > Von: Michael Logue [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 27. September 2005 23:13 > > An: u2-users@listserver.u2ug.org > > Betreff: Re: [U2] Good Programming Practice > > Question......... > > > > What about lock management? > > > > 1. Lock all records that are going to be updated ... > > even if the "update" > > is really a "delete" > > 2. Release your locks promptly (either with a > > RELEASE, WRITE or DELETE > > statement) - don't let the program termination be > > the time when record locks are released 3. Use the > > LOCKED clause so the application can decide what to > > do when a record is locked rather than the database > > > > P. Michael Logue > > U2 Technical Support Engineer & > > U2 Products Service Planner > > > > IBM Certified Solutions Expert in U2 Application > > Development IBM Certified U2 UniData Administration > > > > IBM Information Management Division, Software Group > > Phone: 303-773-7846 > > Tie Line: 656-7846 > > Email: [EMAIL PROTECTED] > > > > www.ibm.com/software/data/u2/support > > Open, Query, Update, Search - Online! > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit > > http://listserver.u2ug.org/ > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit > > http://listserver.u2ug.org/ > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
