The first simple but very important method to implement is
handler::has_ transactions( ). It is used to report to the
upper SQL layer that the storage engine has transactional support. The
return value of 1 (
interpreted as the positive answer.
The next two methods of importance are
handler::start_stmt( ) and
handler:: external_lock( ). They both can be
used by a transactional storage engine to start a transaction.
handler::external_lock() is invoked at least
once per table instance during parsing. Originally, the purpose of this
method was to prevent a table that could have been used by some
application outside of MySQL server from being modified. This use of
handler::external_lock() is nowrather
obsolete. However, its strategic position in the hierarchy of calls
makes it very useful for transactional storage engines to perform
per-table-instance initializations to start a transaction.
The one exceptional condition when a transaction can be started by
passing a call to
handler::external_lock() is the
LOCK TABLES statement, which places a manual
table-level lock on a list of tables to be used in the current
connection session. To deal with this problem, the
handler::start_stmt( ) method was added to the
handler class, which is invoked once
per table instance during
A transactional storage engine will usually need a data structure to keep track of the state of the current transaction. The MySQL storage engine architecture meets ...