|
1887.3.2
by Brian Aker
Extended documentation. |
1 |
Using transactions
|
|
1900.2.7
by Stewart Smith
fix docs warning: underline/overline too short for transactional.rst |
2 |
==================
|
|
1887.3.2
by Brian Aker
Extended documentation. |
3 |
|
4 |
.. toctree:: |
|
5 |
:maxdepth: 2
|
|
6 |
||
7 |
start_transaction |
|
8 |
commit |
|
|
1890.2.5
by Stewart Smith
SET AUTOCOMMIT=1 was not completely performing a COMMIT |
9 |
rollback |
|
1887.3.2
by Brian Aker
Extended documentation. |
10 |
savepoints |
11 |
||
|
1994.4.3
by Marisa Plumb
few updates and modifications to admin commands |
12 |
The essence of a transaction is that it groups multiple steps into a single, all-or-nothing operation. Drizzle is a transactional database by default and by design, meaning that changes and queries to the database appear to be Atomic, Consistent, Isolated, and Durable (ACID). This means that Drizzle implements `serializable <http://en.wikipedia.org/wiki/Serializability>`_, ACID transactions, even if the transaction is interrupted. |
|
1994.4.2
by Marisa Plumb
modified transaction docs |
13 |
|
|
1890.2.5
by Stewart Smith
SET AUTOCOMMIT=1 was not completely performing a COMMIT |
14 |
NOTE: Drizzle still supports non-transactional storage engines, and if these are used then you will not get transactional behaviour with them. The default engine is transactional. |
15 |
||
|
1994.5.6
by Stewart Smith
notes on transaction docs. statements can be rolled back, celan up some language around definition |
16 |
Transactions are a group of operations that form tasks and stores them as a single operation, or if that operation is not possible it removes all changes attempted. Transactions are controlled via START TRANSACTION, ROLLBACK, and COMMIT. Savepoints are implemented to allow for a lower level of granularity. |
|
1887.3.2
by Brian Aker
Extended documentation. |
17 |
|
18 |
A COMMIT statement ends a transaction within Drizzle and makes all changes visible to other users. The order of events is typically to issue a START TRANSACTION statement, execute one or more SQL statements, and then issue a COMMIT statement. Alternatively, a ROLLBACK statement can be issued, which undoes all the work performed since START TRANSACTION was issued. A COMMIT statement will also release any existing savepoints that may be in use. |
|
19 |
||
|
2194.5.2
by Andrew Hutchings
Fix SQL markup |
20 |
Drizzle can operate in an autocommit mode, where each statement is committed at the end of statement, via: |
21 |
||
22 |
.. code-block:: mysql |
|
|
1887.3.2
by Brian Aker
Extended documentation. |
23 |
|
|
1994.4.2
by Marisa Plumb
modified transaction docs |
24 |
SET AUTOCOMMIT= 1 |
|
1887.3.2
by Brian Aker
Extended documentation. |
25 |
|
|
1890.2.5
by Stewart Smith
SET AUTOCOMMIT=1 was not completely performing a COMMIT |
26 |
If you set AUTOCOMMIT=1 during a transaction, that transaction will be committed as part of the SET AUTOCOMMIT=1 statement. |
27 |
||
|
1890.2.12
by Stewart Smith
update docs on Transactional DDL support |
28 |
Transactional DDL is currently not supported, although it may be in the future. This means that although currently you will get a ER_TRANSACTION_DDL_NOT_SUPPORTED error message if you try and execute DDL statements within a transaction, in future versions of Drizzle they may succeed. |
29 |
||
|
1994.4.82
by Marisa Plumb
additions and updates to transaction docs |
30 |
Currently DDL operations are performed as a single transaction, but this limitation will be lifted in the future. |
|
1887.3.2
by Brian Aker
Extended documentation. |
31 |
|
|
1994.5.6
by Stewart Smith
notes on transaction docs. statements can be rolled back, celan up some language around definition |
32 |
For various reasons, Drizzle may have to ROLLBACK a statement or transaction |
33 |
without having been asked to do so. Examples include lock wait timeout or |
|
34 |
deadlock detection. Any application using a transactional database system |
|
35 |
needs to be able to deal with such cases. |