Well, you raise a point, but not the one I think you intend. Transactions should be designed to be active for the minimum span of time to avoid the bottleneck mentioned. I would think very carefully about any transaction the cached a large group of updates for a long period of time, say all postings of a select list of transaction. Instead I would put the transaction inside the loop unless there was a very good reason to be able to back out the entire batch of selected updates.
In either case the assignment of a sequential id from a control record is, in and of itself, a data change that should be cached. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Stevenson, Charles > Sent: Sunday, June 12, 2005 4:26 PM > To: [email protected] > Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION START > & COMMIT/RO... > > Charlie, > > I don't see how that addresses the TRANSACTION problem. > If the call to your NEXT.AVAIL.ID routine happens after TRANSACTION > START, the id control item will not be updated nor will its lock be > released until TRANSACTION COMMIT (or rollback) is executed, even though > the NEXT.AVAIL.ID routine says to write and release it. This is a > potential bottleneck if other concurrent processes are wanting to do the > same, waiting for that control item. > > cds > ------- > 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/
