Thank you very much Ann, your explanations are always very good.

Greetings.

Walter.

On Sun, Jan 6, 2013 at 11:54 PM, Ann Harrison <aharrison@...>wrote:

> **
>
>
> On Sun, Jan 6, 2013 at 7:34 PM, W O
> sistemas2000profesional@...>wrote:Hello everybody
>
>
> >
> > - Transaction 510 inserts a new row
> > - Transaction 510 commit
> >
>
> OK, most recent version by transaction 510, committed.
>
>
> > - Transaction 526 start
> > - Transaction 526 updates the row inserted by transaction 510
> >
>
> OK, most recent version by 526, not committed.
>
>
> - Transaction 535 start
> > - Transaction 535 wants to update the row inserted by transaction 510 but
> > unsuccesfully because transaction 526 has locked it
> >
>
> Right. In the default (concurrency or snapshot mode) 535 can not see
> changes made by 526. In any event the most recent version was created by a
> transaction concurrent with 535, thus not updateable by 535.
>
>
> - Transaction 526 commit
> >
> > Can now transaction 535 update the row inserted by transaction 510?
>
> No.
>
>
> > In this
> > case, updates makes for transaction 526 will be lost, right?
> >
>
> In some other MVCC systems, a select for update gets a different result
> than an ordinary select, allowing 535 to see updates made by a concurrent
> transaction that is now committed, so if 535 added 10 to the current value,
> it would consider the change made by 526. Not Firebird. In Firebird, if
> the result was not committed before the updating transaction started, the
> update fails.
>
>
> > Or transaction 535 should first to read the new row commited (the 526)
> > before making the update?
> >
>
> Not in Firebird. The only way the connection that runs 535 can update that
> row is to end that transaction and start a new one.
>
> Good Luck,
>
> Ann
>
>
> [Non-text portions of this message have been removed]
>
>
>


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