From: "Ann Harrison" <aharrison@...>

> At 09:36 AM 6/25/2002 -0500, Woody wrote:
> >If you switch to no-wait transactions, the error will be returned right

away

> >and you can handle it in a loop that keeps trying until it succeeds. In

most

> >cases, this will be a very short time period if it happens at all. You

could

> >even put a counter in the loop that let's the user know the counter is
> >locked by another user after 10 tries (or something like that) and asks

if

> >they want to continue trying or give up and try again later.
>
> That's a formula for "live lock" - a CPU spending 100% of it's time
> retrying transactions.
>

Not if you sleep between tries for a small amount of time. Besides, it's the
only known, (at least to me) good solution to this type of problem. Unless
the program is constantly incrementing the counters, it really isn't a
problem at all. The chances that 2 users are doing this all the time is
small, in most cases. For those other cases, I agree that a better solution
should be implemented. Something like a test edit on the record to lock it
in would work before letting the user actually create a new record that
needs the counter number. Most of it depends on the application and what it
is trying to do.

I think the main problem here, though, is the understanding of how
transaction work. <G>

Woody (TMW)