MySQL Manual | 4 Implementation Details

Table of Contents

4 Implementation of Transaction-Time Support

Implementation of transaction-time support on top of MySQL was simplified by the use of BerkeleyDB with temporal support. When running MySQL on top of BerkeleyDB, the control flow occurs as follows:

SQL Commands -> Scanner/Parser ->   Interpretation in terms of ->   Rows are encoded/decoded -> Commands passed on to
                  (MySQL)           basic operations                into/from bytes             underlying BerkeleyDB

BerkeleyDB with transaction-time support ensures temporal upward compatibility for non-temporal commands. All regular SQL commands are allowed to go through to the underlying database as in the original MySQL.

The interface between MySQL and BerkeleyDB is through a file called sql/ha_berkeley.cc. This file has a class ha_berkeley which is an instance of superclass handler (described in file handler.h). Every table is mapped to a structure called TABLE and this has a member handler pointer called file. The general scheme is as follows:-

+-------------+
| handler*  +-|---> +---------------+
|    file;    |     | virtual    +--|---> write_row (..)
|             |     | functions  +--|---> update_row(..)
|             |     |            +--|---> delete_row(..)
| [ TABLE ]   |     | [ handler ]   |
|             |     |               |
|             |     +---------------+
+-------------+


+----------------+
|             +--|---> DB*
|             +--|---> DB_TXN*
|                |
|  [ha_berkeley] |
|                |
+----------------+

The functions write_row, update_row etc. are implemented by the ha_berkeley class. The DB and DBC structures are used by BerkeleyDB to create and manage tables.

Implementation of the regular MySQL functions are retained due to TUC. Now, we will describe the implementation of the new functions.

CREATE TABLE ... AS TRANSACTION

Description

The scanning of the SQL commands is done with functions in the file sql/sql_lex.cc and the parser commands are created by sql/sql_yacc.yy. The tokens which are recognized by the scanner are listed in the file sql/lex.h. These tokens are used by the scanner and parser. Each token is hashed to a particular integer using a perfect hashing program called sql/gen_lex_hash. Whenever the tokens are changed in the header files, the user should run this program to generate a perfect hash mapping in the file sql/lex_hash.h.

Unsolved Problem

This brings us to the first unsolved problem in this project. The gen_lex_hash function consistently fails to generate a perfect hash function whenever we add a new token to the list (in sql/lex.h). After some trials, we realized that even the original set of tokens caused errors in the generation of the perfect hash function. It is possible that the values had to be tinkered manually.

Execution

Since there is no way to add new tokens at this time, we have reused a token in the original grammar. Instead of having the SQL command as: CREATE TABLE ... AS TRANSACTIONTIME, we have to live with CREATE TABLE ... AS TRANSACTION. Since the actual table gets created in the BerkeleyDB, we need to pass the information that a temporal table is being created to the file sql/ha_berkeley.cc as well as to the file sql/handler.cc, the latter because we have to verify that the type of the table is BerkeleyDB before creating the TABLE structure.

Developed by the TAU Project, Computer Science Department, University of Arizona