BDB Transactions
The previous two columns
in this series have covered general
transactions with InnoDB tables and transaction
isolation levels. This month, we look at transactions with other table
types, specifically BDB tables, and all other table types, including the
default MyISAM table type.
BDB Tables are not that
commonly used. Most tables tend to be either the default MyISAM table type, or,
for those specifically wanting ACID compliance, InnoDB. BDB (standing for BerkeleyDB)
is the poor relation as far as MySQL goes, a table type that precedes InnoDB,
and was included for its transactional capability, but which never achieved as
much popularity. The BDB format itself is stable (it is supplied by a third
party – Sleepycat Software), but the MySQL interface to it is not yet
‘production’.
mysql>CREATE TABLE bdb_table(f INT) TYPE = BDB
First up, note a very
important difference in the default behavior of BDB tables compared with InnoDB
tables. From one connection, run the following:
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO bdb_table VALUES(1);
Query OK, 1 row affected (0.00 sec)
From a
second connection, see what the table contains:
mysql> SELECT * FROM bdb_table;
Note that the connection
hangs – it is waiting for the other connection to COMMIT its transaction before
returning a result. Remember that InnoDB tables returned a result based upon
the data before any other uncommitted transactions had begun. Commit the
transaction, and the result appears:
Connection
1:
mysql> COMMIT; Query OK, 0 rows affected (0.00 sec)
Connection
2:
mysql> SELECT * FROM bdb_table;
+——+
| f |
+——+
| 1 |
+——+
1 row in set (7.08 sec)
This default behavior
could lead to performance problems in your applications, and is one of the
reasons for InnoDB’s greater popularity.
Autocommit
MySQL’s default behavior
is to automatically commit statements not explicitly wrapped in a transaction.
As we saw here
with InnoDB tables, this means any statement that does not have a BEGIN
preceding it will be immediately carried out (as if you were using the
non-transactional MyISAM table type), as demonstrated below.
From
Connection 1:
mysql> INSERT INTO bdb_table VALUES(2); Query OK, 1 row affected (0.00 sec)
Connection
2:
mysql> SELECT * FROM bdb_table;
+——+
| f |
+——+
| 1 |
| 2 |
+——+
2 rows in set (0.00 sec)
You can circumvent this behavior
by setting AUTOCOMMIT to 0, in which case all statements are treated as if a
BEGIN statement precedes them, for example:
Connection
1:
mysql> SET AUTOCOMMIT=1; Query OK, 0 rows affected (0.01 sec) mysql> INSERT INTO bdb_table VALUES(3); Query OK, 1 row affected (0.00 sec)
Connection
2:
mysql> SELECT * FROM bdb_table;
Again the thread hangs,
waiting for a commit from the first connection.
Connection
1:
mysql> COMMIT; Query OK, 0 rows affected (0.00 sec)
Connection
2:
mysql> SELECT * FROM bdb_table; +------+ | f | +------+ | 1 | | 2 | | 3 | +------+ 3 rows in set (0.00 sec)
Of course, BDB tables
also use the ROLLBACK statement to return the data back to the status it was in
prior to the transaction:
Connection
1:
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO bdb_table VALUES(4);
Query OK, 1 row affected (0.01 sec)mysql> ROLLBACK;
Query OK, 0 rows affected (0.00 sec)mysql> SELECT * FROM bdb_table;
+——+
| f |
+——+
| 1 |
| 2 |
| 3 |
+——+
3 rows in set (0.00 sec)
