At 13:43 -0500 1/8/03, Dane Foster wrote:
><Jeff wrote>
>This looks like it would work, but I would be hesitant to increment my
>own counter rather than getting it from the database. What if someone
>else comes in and commits rows while you are doing the same? then your
>counter *may* be off.
></Jeff wrote>
>
>I thought about that, that is why we obtain a read lock on the table
>to prevent
>anyone from writing to it while we do our thing. But you made me thing about
>something that I didn't think about before. What happens if some
>other code is
>doing the exact same thing we are doing at the same time? Simple, obtain a
>write lock along w/ the read lock. This guarantees that no reading or writing
>can take place until we are done with our update, and since the table can't be
>modified by anyone but us it seems pointless to ask the server for
>the keys when
>we can easily figure out what they are going to be. The other benefit of
>calculating the keys ourselves is it saves us a network trip.
A write lock will allow you to write *or* read. No need to obtain
both locks...
>
>
>
>Dane Foster
>Equity Technology Group, Inc.
>http://www.equitytg.com
>954.360.9800
>----- Original Message -----
>From: "Jeff Mathis" <jmathis@stripped>
>To: "Dane Foster" <dfoster@stripped>
>Cc: <java@stripped>
>Sent: Wednesday, January 08, 2003 13:20
>Subject: Re: retrieving auto-generated keys on bulk insert
>
>
>This looks like it would work, but I would be hesitant to increment my
>own counter rather than getting it from the database. What if someone
>else comes in and commits rows while you are doing the same? then your
>counter *may* be off.
