| Subject | Re: [firebird-support] Re: Is UPDATE in read-committed transaction atomic? |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2007-11-05T15:29:40Z |
jaratulpas wrote:
transaction than a read-committed, just more consistency.
most recent version is protected and can not be overwritten by a
concurrent transaction. In this case, several transactions could
perform the read involved in the update, but only the first one
to return its new value will succeed. If other concurrent transactions
attempt to update or delete the record, they will wait until the
one that did the update finishes. If it commits, they will get an
error. If it fails, the first one to return a new value will proceed,
and the others will return to their wait state.
update conflict reported as a deadlock. Update conflicts are reported
as deadlocks (with a secondary message) because the recovery methods
for the two errors are the same. End your transaction and try again.
Regards,
Ann
>OK. That seems odd because there are no more waits in a snapshot
> Yes, we measured the performance of both modes with our application
> and the 'snapshot' mode was much slower. It is not a typical business
> application, however.
transaction than a read-committed, just more consistency.
>The row is not locked - other transactions can read it. However, the
>>> Is the statement
>>> update object set cnt = cnt + 1 where id = 'a';
>>> safe, i.e. is the row locked for the duration of the update
> statement?
>> No, the row isn't locked at all, but yes, the statement is safe,
>> though it will lead to deadlocks.
>
> Could you please tell me more about the mechanics? How can it lead to
> deadlocks if the row is not locked?
most recent version is protected and can not be overwritten by a
concurrent transaction. In this case, several transactions could
perform the read involved in the update, but only the first one
to return its new value will succeed. If other concurrent transactions
attempt to update or delete the record, they will wait until the
one that did the update finishes. If it commits, they will get an
error. If it fails, the first one to return a new value will proceed,
and the others will return to their wait state.
>No one can commit a new version in the middle, but yes, this is an
> The only way I can imagine is that the whole 'update' statement refers
> to the same version of the row (even of someone commits a new version
> in the middle) and that the 'deadlock' is actually conflicting update
> reported as deadlock.
update conflict reported as a deadlock. Update conflicts are reported
as deadlocks (with a secondary message) because the recovery methods
for the two errors are the same. End your transaction and try again.
Regards,
Ann
>
> Best regards, Jaar
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>