6AtomicityAll transformations in the course of transaction are treat as ONE, impartible transformation.Pivotal and most visible attribute.Nesting and save points.
7When transaction ends (anyhow), system must be in consistent state. ConsistencyWhen transaction ends (anyhow), system must be in consistent state.System could be in the inconsistent state during transaction.Depends on how „Consistent state“ is defined.
8IsolationTransactions are isolated from each other, so they don‘t mutually interfere.Source of all trouble with transactions.Desirable for consistencyHorrible for concurrency
9DurabilityAfter (and only after) the transaction is successfully completed, all transformations are permanent.Special meaning of commit (and rollback).
10Implementation strategies (Atomicity and Durability) Changes held in memory, written on Commit ?Changes immediately written to database, with recovery information:Outside the database (Transaction log)Right in database (Row versions)
11Isolation – Cardinal problem In ideal isolation, all updates are mutually exclusive with any other operation (including read).
15Read Uncommitted Also called „Dirty Read“ Very basic (update) consistencyHighest concurrencyAcceptable for transactions that do not read dataNot supported by Firebird
16Read Committed Basic consistency Good for Cannot read uncommited changesNon-repeatable readsPhantom rowsGood for„Change monitoring“ transactionsTransactions that do not depend on repeatable read (mostly update)Supported by Firebird with options:Record versions – Pending changes do not block readsNo record versions – Compatible with SQL standard
17Repeatable Read Higher consistency, much lower concurrency SQL Standard allows phantom rowsSuitable for reports and some calculationsNo direct support in Firebird. Firebird has isolation level called Snapshot (or Concurrency) that is similar to Repeatable Read, but:Do not allows phantom rows.Do not guarantee that transaction can update data that have been read.
18Serializable Total consistency at the cost of very poor concurrency. The only one that do not allow phantom rows.Necessary for some calculations.Supported by Firebird as Snapshot Table Stability (or Consistency). You can get the same result with Snapshot + Table reservation.
19Main differences between SQL standard and Firebird SQL standard is defined along lock&log implementation.Rows locked by update/delete (or insert) could not be read by other transactions. This do not apply for Firebird, except for Read Committed with „No record version“ option.Rows locked by read are updateable by blocking transaction. This do not apply for Firebird, except for Snapshot Table Stability or transactions with table reservation.
22„Optimistic locking“System always knows better what must be protected, and when.All „pending“ changes are always protected.All reads are protected from update for Repeatable Read and Serializable (SQL standard). Firebird protects only Snapshot Table Stability or on demand (table reservation).
23Table reservation Available for all Firebird isolation levels. Tables are reserved for the specified access when the transaction is started (prevent possible deadlocks and update conflicts that can occur if locks are taken only when actually needed).Fine-grained access specification for individual tables:Shared read: All others can read and update, most liberalShared write: All others except „Serializable“ can read and update.Protected read: All can only read.Protected write: All except „Serializable“ can read, but only blocking transaction can write.
24Lock resolutionWait The default, transaction will wait until locked resources are released. Once the resources are released, the transaction retries its operation.No wait Transaction returns a lock conflict error without waiting for locks to be released.
25MGA implementation I. Record versions Bitmap of Transaction States Linked list starting from most recent version.Each version contains transaction number.Bitmap of Transaction StatesUsed to determine the visibility of particular version for a transaction.Snapshot transactions have a snapshot created when they start.Read Committed transactions use shared map with actual states.
26MGA implementation II.Transaction state bitmap from OIT (not committed transaction)00 – Active01 – Limbo10 – Dead (rollback)11 – CommittedStored in database as Transaction Inventory Pages (TIP).1K page can hold up to 4016 transactions (4 transactions per byte * (1024 bytes – 16 byte header – 4 byte next TIP page number))On first db attachment:Transaction state bitmap is restored from TIPsActive transactions are marked as dead
27MGA implementation III. T-Shirt Question! Current Transaction StatesChain of row versions60 – ActiveRC59 – ActiveS58 – Rollback57 – Commit56 – Commit55 – Active54 – Rollback53 – ActiveOldest Active Transaction (OAT)52 – Commit51 – Commit50 – RollbackOldest Interesting Transaction (OIT)6056525032Transaction 53 will get version 56
28MGA implementation IV.New row version is always written in the place of old version.Previous version is moved to another place, preferably on the same page.When there is no more room on Data page for previous version or new version, everything starts to deteriorate.
29Data page Page header Page number Relation Number N Offset_1, Size_1 Offset_N, Size_NData - row 1Data - row 2Data - row 3Data - row N…
30MGA implementation V.All versions from dead transactions or versions from transactions beyond first committed transaction lower than OAT could be removed.Unnecessary versions are detected whenever Firebird access a row. This process is called Garbage Collection.Classic removes unnecessary versions immediately.Super Server marks them for separate GC thread.Garbage collection doesn't ensure that all row versions from dead transactions are removed.Long-running transactions are a disaster.
31MGA implementation VI.Commit/Rollback Retaining doesn't really ends the transaction.Rollback requested by client may use an undo log:If undo log is not too big.If undo log is not disabled by client.Read Only transactions in Read Committed isolation level do not block garbage collection.
32MGA implementation VII. Save pointsHave been there for long time for internal useModified and surfaced for general use in Firebird 1.5 SAVEPOINT name ROLLBACK [WORK] TO [SAVEPOINT] nameUndo log for save pointStarts at transaction levelCreated for statements, stored procedures and triggersNested when necessary and merged upMuch improved in Firebird 1.5 (use of B+tree)
33MGA implementation VIII. „Frozen“ Oldest Interesting TransactionSlow down start of new transactionsEats server resourcesGap between OIT and current transaction may start the Sweep process (depend on sweep interval settings)Sweep does the garbage collection of all unnecessary versions in database + advance OITFull database GC (by gbak for example) do not replace sweep!
34MGA implementation IX. Explicit record locking New in Firebird 1.5 SELECT <...> [FOR UPDATE [OF col [, col ...]] [WITH LOCK]]For use with server-side cursors onlyDosn‘t mess with record versions like „fake update“Use at your own risk
35Firebird tips & tricksAvoid use of Commit Retaining and stable db_keys.Avoid designs that require many changes to single row.Avoid designs that require updates as part of insert.If transaction reads many rows for later update, use table reservation.For long-running „change monitoring“ transactions, use Read Committed with Read Only attribute, or events.Do not perform many changes in nested procedures.Keep number of changes per transaction reasonably small.
36http://www.ibphoenix.com We have answers That‘s all (for now)We have answers