learntrade wrote:

>
> 1)What kind of conflicts?

isc_update_conflict.

> Assuming ilReadCommitted and lrWait, does the waiting read
> A)(repeatedly) attempt to re-read the same record generation it tried
> before?

It reads the record header, then waits until the concurrent transaction
commits or rolls back and then re-reads the record (including fetching
record data).

> 2)IBPP (source-code wise, I haven't debug-stepped it)
> A)does explicitly set isc_tpb_no_rec_version for ilReadCommitted
> (core\transaction.cpp, lines 316 v2-5-2-0, or 308 v2-5-2-2)

That's a pity. no_rec_version is in fact an emulation of the blocking
engines where writers block readers. I doubt it makes a lot of sense to
use this mode in a MGA engine.

> B)leaves default (docs I've read say should be no_rec_version) when
> using ilConcurrency

no_rec_version is used only for read committed transactions. It makes no
sense for concurrency (aka snapshot) ones.

> But, if I've understood you, with ilReadCommitted, lrWait, and
> isc_tp_no_rec_version (repeat - which IBPP _appears_ to be using), I
> _should_ be getting the desired result, and _not_ a deadlock - Correct?

Yes, but I cannot say for sure without seeing your code. Maybe I missed
something in your application logic.


Dmitry