begriffs open source - ai-pg/blob - full-docs/txt/tutorial-transactions.txt

   1
   2 3.4. Transactions #
   3
   4    Transactions are a fundamental concept of all database systems. The
   5    essential point of a transaction is that it bundles multiple steps into
   6    a single, all-or-nothing operation. The intermediate states between the
   7    steps are not visible to other concurrent transactions, and if some
   8    failure occurs that prevents the transaction from completing, then none
   9    of the steps affect the database at all.
  10
  11    For example, consider a bank database that contains balances for
  12    various customer accounts, as well as total deposit balances for
  13    branches. Suppose that we want to record a payment of $100.00 from
  14    Alice's account to Bob's account. Simplifying outrageously, the SQL
  15    commands for this might look like:
  16 UPDATE accounts SET balance = balance - 100.00
  17     WHERE name = 'Alice';
  18 UPDATE branches SET balance = balance - 100.00
  19     WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice');
  20 UPDATE accounts SET balance = balance + 100.00
  21     WHERE name = 'Bob';
  22 UPDATE branches SET balance = balance + 100.00
  23     WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
  24
  25    The details of these commands are not important here; the important
  26    point is that there are several separate updates involved to accomplish
  27    this rather simple operation. Our bank's officers will want to be
  28    assured that either all these updates happen, or none of them happen.
  29    It would certainly not do for a system failure to result in Bob
  30    receiving $100.00 that was not debited from Alice. Nor would Alice long
  31    remain a happy customer if she was debited without Bob being credited.
  32    We need a guarantee that if something goes wrong partway through the
  33    operation, none of the steps executed so far will take effect. Grouping
  34    the updates into a transaction gives us this guarantee. A transaction
  35    is said to be atomic: from the point of view of other transactions, it
  36    either happens completely or not at all.
  37
  38    We also want a guarantee that once a transaction is completed and
  39    acknowledged by the database system, it has indeed been permanently
  40    recorded and won't be lost even if a crash ensues shortly thereafter.
  41    For example, if we are recording a cash withdrawal by Bob, we do not
  42    want any chance that the debit to his account will disappear in a crash
  43    just after he walks out the bank door. A transactional database
  44    guarantees that all the updates made by a transaction are logged in
  45    permanent storage (i.e., on disk) before the transaction is reported
  46    complete.
  47
  48    Another important property of transactional databases is closely
  49    related to the notion of atomic updates: when multiple transactions are
  50    running concurrently, each one should not be able to see the incomplete
  51    changes made by others. For example, if one transaction is busy
  52    totalling all the branch balances, it would not do for it to include
  53    the debit from Alice's branch but not the credit to Bob's branch, nor
  54    vice versa. So transactions must be all-or-nothing not only in terms of
  55    their permanent effect on the database, but also in terms of their
  56    visibility as they happen. The updates made so far by an open
  57    transaction are invisible to other transactions until the transaction
  58    completes, whereupon all the updates become visible simultaneously.
  59
  60    In PostgreSQL, a transaction is set up by surrounding the SQL commands
  61    of the transaction with BEGIN and COMMIT commands. So our banking
  62    transaction would actually look like:
  63 BEGIN;
  64 UPDATE accounts SET balance = balance - 100.00
  65     WHERE name = 'Alice';
  66 -- etc etc
  67 COMMIT;
  68
  69    If, partway through the transaction, we decide we do not want to commit
  70    (perhaps we just noticed that Alice's balance went negative), we can
  71    issue the command ROLLBACK instead of COMMIT, and all our updates so
  72    far will be canceled.
  73
  74    PostgreSQL actually treats every SQL statement as being executed within
  75    a transaction. If you do not issue a BEGIN command, then each
  76    individual statement has an implicit BEGIN and (if successful) COMMIT
  77    wrapped around it. A group of statements surrounded by BEGIN and COMMIT
  78    is sometimes called a transaction block.
  79
  80 Note
  81
  82    Some client libraries issue BEGIN and COMMIT commands automatically, so
  83    that you might get the effect of transaction blocks without asking.
  84    Check the documentation for the interface you are using.
  85
  86    It's possible to control the statements in a transaction in a more
  87    granular fashion through the use of savepoints. Savepoints allow you to
  88    selectively discard parts of the transaction, while committing the
  89    rest. After defining a savepoint with SAVEPOINT, you can if needed roll
  90    back to the savepoint with ROLLBACK TO. All the transaction's database
  91    changes between defining the savepoint and rolling back to it are
  92    discarded, but changes earlier than the savepoint are kept.
  93
  94    After rolling back to a savepoint, it continues to be defined, so you
  95    can roll back to it several times. Conversely, if you are sure you
  96    won't need to roll back to a particular savepoint again, it can be
  97    released, so the system can free some resources. Keep in mind that
  98    either releasing or rolling back to a savepoint will automatically
  99    release all savepoints that were defined after it.
 100
 101    All this is happening within the transaction block, so none of it is
 102    visible to other database sessions. When and if you commit the
 103    transaction block, the committed actions become visible as a unit to
 104    other sessions, while the rolled-back actions never become visible at
 105    all.
 106
 107    Remembering the bank database, suppose we debit $100.00 from Alice's
 108    account, and credit Bob's account, only to find later that we should
 109    have credited Wally's account. We could do it using savepoints like
 110    this:
 111 BEGIN;
 112 UPDATE accounts SET balance = balance - 100.00
 113     WHERE name = 'Alice';
 114 SAVEPOINT my_savepoint;
 115 UPDATE accounts SET balance = balance + 100.00
 116     WHERE name = 'Bob';
 117 -- oops ... forget that and use Wally's account
 118 ROLLBACK TO my_savepoint;
 119 UPDATE accounts SET balance = balance + 100.00
 120     WHERE name = 'Wally';
 121 COMMIT;
 122
 123    This example is, of course, oversimplified, but there's a lot of
 124    control possible in a transaction block through the use of savepoints.
 125    Moreover, ROLLBACK TO is the only way to regain control of a
 126    transaction block that was put in aborted state by the system due to an
 127    error, short of rolling it back completely and starting again.