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]