--- In firebird-support@yahoogroups.com, Alessandro GARDICH
<gremlin@g...> wrote:

> > 2. Seems you are trying to randomly update records. Nothing

unusual

> > you have many exceptions about lock conflicts (they are named
> > deadlock even if it is simple conflict). In wait mode which you

use

> > scenario is:
> >
> > one transaction updated some record
> > another transaction tried to do the same with this record and

waits

> > what first one will do - if rollback, then it will run further, if
> > commit, it will raise exception.
> >
> > since you always commit, exception is always raised.

Alessandro, sorry, it was Friday syndrome :) I spoke about
concurrency mode, which I usually use for updates. In read_commited
second transaction should be successfull in any case after first's
ending.

> so, what's the difference in a WAIT/NO_WAIT transaction ?
> I espect this behavour on a NO_WAIT transaction.

No, nowait just shouldn't wait at all and report conflict in time of
it's occurance. To be more clear:

1. concurrency nowait - report conflict if in time of attempt to
update there exists uncommited version of this record or if record was
changed and commited after this transaction start.
2. concurrency wait - as I described in first post.
3. read_commited nowait report conflict if in time of attempt to
update there exists uncommited version of this record.
4. read_commited wait _should_ be successful in any case.

Thanks to Marco, he noticed interesting thing about rec_version, and
it seems to me it is bug, read_commited in the sense of updates should
behaviour identically, difference should be on selects only. I checked
it and got the same result as Marco - read_commited rec_version
behaviour is exactly like concurrency! I'll consult with FB
developers, but IMO it is bug.

Thank you both for report and discussion,
Alexander.