further clarification sought - embedded below...

--- In firebird-support@yahoogroups.com, Dmitry Yemanov <dimitr@...>
wrote:

>
> learntrade wrote:
> >
> > After initial setup and connection, the program starts a transaction
> > and calls a stored procedure that performs an update to a record, and
> > then selects the updated value from the record to return. The
> > calling program additionally takes the returned value and performs an
> > insert into a different table, still within the same transaction.
> > Then, the transaction is committed.
> >
> > Multiple clients following this sequence, _should_ (I think) therefore
> > all be "held" at the attempt to update the ("generator") record, until
> > the other transaction (if any) is released.
>

<snip>

>With
> no_rec_version, the waiting will be performed when *reading* the record
> for update, so your scenario should succeed. But the problem is that
> there's no explicit queue of record-level waiters, so if more than two
> concurrent applications are in game, I'm afraid you cannot guarantee
> their execution without conflicts.

1)What kind of conflicts?
Assuming ilReadCommitted and lrWait, does the waiting read
A)(repeatedly) attempt to re-read the same record generation it tried
before?
B) per docs I've read, attempt to read the current "latest" generation
(which, with >2 clients in play, might have progressed beyond previous
attempt [I'm guessing maybe even with just 2 in play with classic
under windows])?
C)?

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)
B)leaves default (docs I've read say should be no_rec_version) when
using ilConcurrency

I've tried both ilReadCommitted, and ilConcurrency with same results...
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?

So, is this a bug?

>
> BTW, I really doubt that IBPP uses no_rec_version by default for
> read-committed transactions. But even working in the rec_version mode,
> you may emulate the no_rec_version behaviour using the SELECT WITH LOCK
> feature.
>
>
> Dmitry
>