-
Notifications
You must be signed in to change notification settings - Fork 131
Savepoints
TokuDB uses a stack of nested transactions to implement savepoints. For each savepoint defined in a transaction, TokuDB creates a new child transaction of the transaction on the top of the stack and pushes the new transaction onto the stack. All transaction operations after a savepoint uses the transaction associated with the savepoint. A rollback to savepoint will pop the stack until the savepoint is found and abort the transaction associated with the savepoint.
Suppose that there are several savepoints defined in a transaction labelled S0, S1, S2, ... SN. The TokuDB transaction stack that corresponds to these savepoints is T0, T1, T2, ... TN, where T(i) is a child transaction of T(i-1). This data structure efficiently supports savepoint rollback since an abort of the savepoint's transaction will abort all of its children.
MySQL will allocate a tokudb_savepoint_info struct for each savepoint. This struct maps a savepoint to a TokuDB transaction pointer. TokuDB gets passed a tokudb_savepoint_info struct in each of the following three handlerton methods.
The tokudb_savepoint handlerton method is called when a savepoint is being created. This method creates a child transaction of trx->sp_level and saves the new child transaction in trx->sp_level. Subsequent storage engine operations will use the new child transaction since they pick up the transaction pointer from trx->sp_level. In addition, this method stores the new child transaction in the tokudb_savepoint_info object that MySQL passed to this method.
The tokudb_rollback_savepoint handlerton method is called when a transaction is being rolled back to this savepoint. This method uses the tokudb_savepoint_info object to find the transaction associated with the savepoint. This child transaction is aborted. The top of the transaction stack is set to the parent of this child transaction and a new savepoint is created.
The tokudb_release_savepoint handlerton method is called when a savepoint is being released from the set of named savepoints. If the transaction associated with the savepoint has no children, then that transaction is committed and its parent transaction inherits all of its changes. If the transaction associated with the savepoint does have a child, then that transaction is ignored (neither committed or aborted).
Since TokuFT only allows a nested transaction depth of about 253, a TokuDB transaction is similarly limited in the number of savepoints that it can define.