Understanding MySQL Internals

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 handler 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 handlerton functions. This is understandable: the handler subclass methods are conceptually associated with a particular table instance, while the handlerton functions are associated only with ...