firebird/firebird-mirror
firebird/firebird-mirror
8
0
Fork 1
mirror of https://github.com/FirebirdSQL/firebird.git synced 2025-01-23 00:03:02 +01:00
Code Issues

Update documentation.

Browse Source
This commit is contained in:
hvlad 2018-07-16 16:05:10 +03:00
parent 0173d55597
commit 905653a517
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/README.read_consistency.md
View File

@ -127,14 +127,23 @@ So, there are three kinds of read-committed transactions now:
When statement executed within read committed read consistency transaction its database view is When statement executed within read committed read consistency transaction its database view is
not changed (similar to snapshot transaction). Therefore it is useless to wait for commit of not changed (similar to snapshot transaction). Therefore it is useless to wait for commit of
concurrent transaction in the hope to re-read new committed record version. Similarly, engine concurrent transaction in the hope to re-read new committed record version. On read, behavior is
doesn't wait and re-read record when update conflict happens. Instead, engine undoes all work similar to read committed *no record version* transaction - do not wait for active transaction and
done up to top-level statement, creates new snapshot and restart top-level statement execution. walk backversions chain looking for record version visible to the current snapshot.
When update conflict happens engine behavior is changed. If concurrent transaction is active,
engine waits (according to transaction lock timeout) and if concurrent transaction still not
committed, update conflict error is returned. If concurrent transaction is committed, engine
creates new snapshot and restart top-level statement execution. In both cases all work performed
up to the top-level statement is undone.
This is the same logic as user applications uses for update conflict handling usually, but it This is the same logic as user applications uses for update conflict handling usually, but it
is a bit more efficient as it excludes network roundtrips to\from client host. This restart is a bit more efficient as it excludes network roundtrips to\from client host. This restart
logic is not applied to the selectable stored procedures if update conflict happens after any logic is not applied to the selectable stored procedures if update conflict happens after any
record returned to the client application. In this case *isc_update_conflict* error is returned. record returned to the client application. In this case *isc_update_conflict* error is returned.
Note: by historical reasons isc_update_conflict reported as secondary error code with primary
error code isc_deadlock.
### No more precommitted transactions ### No more precommitted transactions