--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

> The more transactions you have sitting around uncommitted,
> waiting....waiting..., the less likely it becomes that much progress
> will be made. You don't say how you are logging but, if it is to a
> table in the database, then that's a source of bottlenecks and
> waiting, also; and log records won't get committed either.
>

Hello Helen

Thanks for the detailed reply, throws a lot of light on the issue and
I will refer to the IBO technical page as suggested. Couple of further
questions for clarification if I may :

- by throwing an exception with an update conflict I presume the SP
will return to the calling program. If so, I assume that I would need
to check for the exception and call the SP again until successful ? Or
perhaps loop in the SP until successful.

- If I call an executable SP to do updates from a Delphi program,
using transaactions and specifying read committed, do calls from other
clients which may also want to update the same data not wait until my
transaction commits, then the next client grabs the data, updates,
commits, followed by the next...and so on ? If I understand you
correctly once there is a lock held by a transaction others will fail
even if the lock (and data changes) are committed by the original
transaction.

Thanks
Rob