Chapter 11. Transactions
In the MySQL architecture, the majority of the burden for implementing transactions is placed on the storage engine. The details of transaction logging, row or page locks, implementing the isolation levels, commits and rollbacks, and other critical components of transaction implementations vary greatly from storage engine to storage engine. However, every storage engine has to use the same interface to communicate with the upper SQL layer. Thus the focus of this chapter will be to outline how to integrate an already existing transactional storage engine into MySQL.
InnoDB is the most robust transactional storage engine in MySQL. Therefore I will use it as an example and analyze why things are done a certain way.
Overview of Transactional Storage Engine Implementation
Chapter 7 discussed
the basics of implementing a storage engine. As you may recall, there
are two parts to integrating a custom storage engine into MySQL:
defining and implementing the
subclass, and defining and implementing the
handlerton. We discussed these in a fair
amount of detail.
While the proper implementation of transactions definitely
requires a great attention to detail in implementing the virtual methods
of the handler subclass, the core of the transaction-specific work
happens in a few
functions. This is understandable: the
handler subclass methods are conceptually
associated with a particular table instance, while the
handlerton functions are associated only with ...