WL#2952: Transaction Support in Federated Handler
Affects: Server-7.0 — Status: On-Hold — Priority: Low
Implemented in multiple stages: Stage 1 * Create a transaction context. * Create a connection for each table in a transaction context. Stage 2 * Implement per-table connection pooling Stage 3 * Implement per-server connection pooling Stage 4 (optional) * Allow differing 'backend' transports to be used such as ODBC. Stage 5 (optional) * Implement XA support for two phase commit.
Implement the handler methods and handlerton functions for commit, rollback, external_lock, etc. Stage 1 * Create a transaction class federated_trx * Create a transport class federated_io Stage 2 * Implement simple LIFO queue in per-table shared structure. Stage 3 * Implement a cache for per-server information * Move LIFO transport queue into per-server structure Stage 4 (optional) * Declare federated_io class as a abstract virtual class. * Declare new classes for implementing transports. Stage 5 (optional) * When beginning a transaction, either copy the MySQL XID or create a new one for use by Federated transports. * When a connection joins a transaction, begin the XA transaction using the stored XID. * If a cycle is detected (responsibility of remote XA server to detect) then an error must be reported. * XA functionality should be optional.
Eventually, we will wish to discover all attributes of a remote table, but for the moment, we will make some assumptions. At present, the connection assumes autocommit is true, first we will change this assumption. When a federated handler object has open table called, we will issue a "SET AUTOCOMMIT=0" then, at each "commit", we will issue a "COMMIT" on the remote table. We will add a "federated_trx_data" struct to hold pointers to the handlers involved in a transaction. implement the "commit" and "rollback" functions for the federated handlerton and "ha_federated::external_lock"
Copyright (c) 2000, 2016, Oracle Corporation and/or its affiliates. All rights reserved.