thanks for the reply.

I run in READ_COMMITTED|NO_REC_VERSION|WAIT transactions.
So it is not asking over-and-over again, if there
is a conflict, the transactions wait until the active
transaction commits at which time they get the lock-conflict
or deadlock exception and only retry once.

It seems to work really well because it saves roundtrip times
to the client and full rollbacks.

If I use READ_COMMITTED|NO_REC_VERSION|WAIT is this a better
method than retrying in the client code?

thanks,

stan

--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> Stan wrote:
> >
> > According to The great Firebird Book, try/catch blocks
> > within a stored procedure act as "nested" transactions.
> >
>
> The nested transactions have the same snapshot of the database
> as the outer transaction, so asking the question over and over
> is going to get the same answer for snapshot/concurrency
> transactions. If you run that procedure in read-committed
> mode, it will eventually see the conflicting record and the
> new data when the second transaction commits. On the other
> hand, it will waste a lot of CPU testing over and over until
> the commit happens.
>
> So generally, I say no, that's not a good way to hand lock
> conflicts.
>
>
> Regards,
>
>
> Ann
>