Thank you Helen, very counted on that turn the discussion and you give a
definitive answer.
My question might seem strange, but to me the documentation does not
explain clearly how transactions are handled in Firebird
Regards
W dniu 10.03.2014 22:18, Helen Borrie pisze:
At 09:20 a.m. 11/03/2014, Åukasz BÄ…czek wrote:
>This sentence:
>"SERIALIZABLE: This is the strictest isolation level, Which enforces
transaction serialization. Date accessed in the context of a
serializable transaction can not be accessed by any other transaction."
Here is the whole quote. The asterisks for emphasis were inserted by me:
<..>
Isolation Level: A transaction isolation level defines the interaction
and visibility of work performed by simultaneously running
transactions. There are four transaction isolation levels
****according to the SQL standard****:
READ COMMITTED: A transaction sees only data committed before the
statement has been executed.
READ UNCOMMITTED: A transaction sees changes done by uncommitted
transactions.
REPEATABLE READ: A transaction sees during its lifetime only data
committed before the transaction has been started.
SERIALIZABLE: This is the strictest isolation level, which enforces
transaction serialization. Data accessed in the context of a
serializable transaction cannot be accessed by any other transaction.
<..>
Firebird supports only two of those ****SQL-standard**** isolation
levels: READ COMMITTED and REPEATABLE READ (SNAPSHOT). It does not
support READ UNCOMMITTED or SERIALIZABLE.
The most restrictive isolation level in Firebird is SNAPSHOT TABLE
STABILITY, which dwells somewhere between the concepts of REPEATABLE
READ and SERIALIZABLE. It denies writes to subsequent transactions and
it cannot see table rows that currently have uncommitted writes. It
comes close to the quality of SERIALIZABLE when the extremes of other
transaction conditions (access mode; and table reservation) are
applied; otherwise STS transactions don't block READ access. In
practice, SNAPSHOT TABLE STABILITY should be avoided as it really has
very few practicable use cases and, of course, it will make life for
multiple users very frustrating.
By contrast, use of the pessimistic locking mechanism FOR UPDATE
blocks all access to each row in turn as it is encountered by
competing transactions. Once each row's pessimistic lock is secured,
blocked read access remains for all subsequent transactions until the
"offending" transaction is committed. IMHO, it was a pretty useless
"enhancement" during the Firebird era, that was unnecessary and
horribly difficult to use correctly. With Firebird you can get ample
control over write conflicts using SNAPSHOT transactions, without
jamming up the flow with pre-emptive blocking of any kind.
Helen Borrie, Support Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book" and "The Firebird Book Second Edition"
http://www.firebird-books.net
__________________________________________________________
