SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Understanding Transaction Models: Dependencies, Rules, and Structures

samson-parks avatar
samson-parks
27 diapositives · 424 Views · Nov 13, 2014

This document explores transaction models, focusing on their structural and dynamic dependencies within hierarchical systems. It discusses principles of transaction management such as flat transactions, savepoints, and chained transactions, including triggering rules for state transitions and the rollback/commit processes. The summary also covers nested transactions and their hierarchical nature, presenting a comprehensive view of how transactions interact and rely on one another, ensuring efficient handling of system resources and error recovery in complex applications.

Understanding Transaction Models: Dependencies, Rules, and Structures - slide 1
01 / 27Understanding Transaction Models: Dependencies, Rules, and Structures
1 / 17

Télécharger la présentation

Understanding Transaction Models: Dependencies, Rules, and Structures
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. A Notation for Transaction Models Adapted from slides by J. Gray & A. Reuter

  2. Dependencies Between Transactions • Structural dependencies • Reflect the hierarchical organization of the system into abstract data types of increasing complexity. • reflects the invocation hierarchy of the system. • Dynamic dependencies • Arises from the use of shared data. • Can envelop any number of otherwise unrelated atomic actions.

  3. A Graphical Metaphor for Rules

  4. Describing Flat Transactions A B C A B C A B C system system system A C A C A C trigger A B C A B C B A C T T T A C A C A C a) Transaction T is active; b) Termination scenario 1: c) Termination scenario 2: an abort of the system Transaction T has committed; Same as scenario 1, but transaction will cause it all of its event ports are T assumes the final abort to roll back, too. deactivated; the final state is state. highlighted.

  5. The Rule Language • For each atomic action define a set of rules that define its effect. • One rule for each state transition the action can perform • The structure of an arbitrary rule is as follows: (rule identifier):(preconditions) -> (rule modifier list), (signal list), (state transition) Indicates signal that cause rule to fire. How rule set is changed by firing. Signal sent as result of firing.

  6. Rules For Flat Transactions • SB(T) : -> +(SA(system)|SA(T)),, BEGIN_WORK • Rule is fired when signal ‘Begin Work’ is received. • Adds rule that causes ‘Abort Work’ signal to be sent when SA(system) rule is fired. • SA(T) : ->(delete(SB(T)),delete(SC(T))),, ROLLBACK_WORK • Disables rule SB(T) and SC(T). • SC(T) : -> (delete(SB(T)), delete(SA(T))),, COMMIT_WORK • Disables rule SB(T) and SA(T).

  7. Flat Transactions With Savepoints

  8. Flat Transactions with Savepoints • Allow for partial rollback • In travel agent problem had to rollback entire transaction if one leg could not be reserved. • Instead do the following • Attempt to reserve San Francisco to Frankfurt if successful establish savepoint 2 • Attempt to reserve Frankfurt to Milan - if successful establish savepoint 3. • If not rollback to savepoint 2 and try for Frankfurt to Rome - if successful establish savepoint 4.

  9. A B C A B C A B C system system system A C A C A C trigger trigger trigger A B C A B C A B C S1 S1 S1 A C A C A C trigger trigger a) Transaction has started, trigger trigger establishing savepoint 1 A B C A B C S2 S2 A C A C trigger b) Next savepoint trigger S2 has been taken A B C S3 A C c) Next savepoint S3 has been taken Flat Transactions With Savepoints

  10. Flat Transactions With Savepoints • The rule system for transactions with savepoints SB(Sn) : -> ,,BEGIN WORK SA(R) : (R<Sn) -> ,SA(Sn-1), ROLLBACK WORK SC(Sn) : -> ,SC(Sn-1), COMMIT WORK SS(Sn) : -> +(SA(Sn)|SA(Sn + 1)), SB(Sn + 1),

  11. Chained Transaction • Sequence of transactions • Upon commitment of one transaction, next one begins • Not possible to rollback beyond current transaction • When one transaction ends all resources not needed in future are freed, e.g., • give up unnecessary locks • close unneeded cursors

  12. A B C A B C A B C system C1 C2 A C A C A C trigger trigger a) The first transaction in the chain has been started; start of the second one will be triggered by commit of the first one. A B C A B C A B C A B C system C1 C2 C3 A C A C A C A C trigger trigger b) The first transaction in the chain has committed; the second one got started as part of commit of C1. Now the second one is structurally dependent on "system". Chained Transactions

  13. Restart Processing

  14. Chained Transactions vs. Savepoints • Workflow structure • Both allow a substructure to be imposed on a long-running application program. • Commit versus savepoint • Chaining step irrevocably completes a transaction • Rollback is limited to the currently active transaction. • Lock handling • COMMIT allows the application to free locks that it does not later need.

  15. Chained Transactions vs. Savepoints • Work lost • Savepoints allow more flexible state restoration. • Savepoints are not persistent - enclosing transaction is aborted. • After failure entire transaction must be redone. • With chained transactions, the state of the most recent commit is restored. • Less work is lost in that situation.

  16. Nested Transactions • Definition summarized from [Moss81] • A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. • Transactions at the leaf level are flat transactions. The distance from the root to the leaves can be different for different parts of the tree. • The transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. • A sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. • The rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back.

  17. Nested Transactions • Commit rule • The commit of a sub-transaction makes its results accessible to the parent transaction only. • The sub-transaction will finally commit (i.e. release its results to the outside world) if and only if it has committed itself locally and all its ancestors up to the root have finally committed. • Rollback rule • If a (sub-) transaction at any level of nesting is rolled back, all its sub-transactions are also rolled back, independent of their local commit status. This is applied recursively down the nesting hierarchy.

  18. Nested Transactions • Visibility rule • All changes done by a sub-transaction become visible to the parent transaction upon the sub-transaction’s commit. • All objects held by a parent transaction can be made accessible to its sub-transactions. • Changes made by a sub-transaction are not visible to its siblings.

  19. Nested Transactions

  20. Nested Transactions Means that effect is conditioned on commit of parent

  21. Nested Transactions vs. Savepoints

  22. Distributed Transactions

  23. Multi-Level Transactions

  24. Using Multi-Level Transactions

  25. Using Multi-Level Transactions II

  26. Using Multi-Level Transactions • Abstraction hierarchy • The entire system consists of a strict hierarchy of objects with their associated operations. • Layered abstraction • The objects of layer n are completely implemented by using operations of layer n-1. • Discipline • There are no shortcuts that allow layer n to access objects on a layer other than n-1.

  27. Multi-Level Transactions • Advantages • Subtransaction can commit immediately • Objects become available to other transactions sooner • Better peformance • Disadvantages • Requires a well-structured and well-understood structure • Requires the definition of a compensating transaction for each subtransaction that commits early • Recovery by compensating transactions often takes longer than physical recovery (copying back the before image).