> Il y a une trentain d'annees, quelqu'un m'avait dit "Ce qui n'est pas
> clair, n'est pas francais."
>

c'est claire :)

What i want to say :

Table_A
Field_A
12

Transac 1 (isc_tpb_wait) :
update Table_A Set Field_A = Field_A + 1;

At the same time

Transac 2 (isc_tpb_wait) :
update Table_A Set Field_A = Field_A + 1;

here we imagine a dead lock will appear !
but we set isc_tpb_wait to say to wait
that the lock dispear

BUT the probleme is that at the begining

Transac_1 Is the first to do the job (FieldA = 12)
Transac_2 wait (FieldA = 12)
Transac 1 finish the job (FieldA = 13)
Transac_2 ok i can do the job ... ooh no i can't because fieldA <> what
it was at the begining 12 :(

it's how Firebird work actually (if i make no mistake)

but you resume it

> In read committed mode, Firebird would return $20 as the balance until
> the transaction that added $80 commits. After the commit, the same
> transaction that saw $20 would see $100, but it still can't add $5
> because the $80 was added by a transaction that was not committed when
> the current transaction started.
>

exactly what i want to say .... but with instruction like FieldA =
FieldA + 1
it's normally doesn't really matter because the transaction saw like
you say $ 80 (after the commit of the first transac and the release of
the lock)
an can do the math ...

> In NuoDB, snapshot transactions get
> update conflicts by default, and read committed transactions wait for
> the conflicting write to be committed so the new value is visible,
> then proceed.
>

yes sad that nuodb still in beta :(



[Non-text portions of this message have been removed]