Refactor txn context management in session #30535
Labels
sig/sql-infra
SIG: SQL Infra
sig/transaction
SIG:Transaction
type/enhancement
The issue or PR belongs to an enhancement.
Introduction
We have some problems for the current transaction context implementation:
No single truth for txn context
Though we have
sessionVars.TxnCtx
to store thestartTS
andInfoSchema
for current txn, we still need to obtain them from other places in some cases. For example, when we are using stale read in implicit transaction to read data,TxnCtx.InfoSchema
andTxnCtx.StartTS
is not set with right values. Instead, the real values are computed in session and passed to planner and executors by method arguments.It seems that
sessionctx.Context.GetInfoSchema
provides the "current" infoschema. But it is not true, it provides the latest infoschema in implicit transaction. This behavior misleads developers a lot.The codes maintaining txn context in different scenarios are serious coupling
We have several scenarios (i.e. RR/RC isolation, stale/historical read ...) providing txn context. These codes are mixed up not have not been modularized. So it is hard to read these codes.
Design
To solve the above problems. We'll introduce a new interface
TxnManager
which provides some methods to manage transaction context in session. The interface is like this:The get method, for example, GetTxnInfoSchema should be a single truth to return the real txn infoschema considering all scenarios.
For maintaining the context for different scenarios, we can also introduce a new interface
TxnContextProvider
:It provides two kind of methods. The first methods provide some lifecycle hooks, they should be called by
TxnManager
at the corresponding stage. The second methods provide context for their own scenario. After this, we can haveRRIsolationContextProvider
,RCIsolationContextProvider
,StaleReadContextProvider
...TxnManager
should provide some methods to get/set the current provider:We can obtain
TxnManager
from session like this:GetTxnManager is defined as a factory method:
Refactor path
At first step of refactoring, we can implement the "read" methods of the
TxnManager
which only "wraps" the current implements. At this time,SimpleTxnContextProvider
can be provided to do the wrap works. We should also add some unit tests to ensure that the context get fromTxnManager
and the old interface equals.After step 1, the codes are still using the old interface to get the txn context. Then we should migrate these codes to reading the new interface for
TxnManager
. If we did well in step1, this step should be safe.After all interfaces are migrated to
TxnManager
. We can introduce more context providers to replaceSimpleTxnContextProvider
for each scenario. For example, we can introduceStaleReadTxnContextProvider
to provide stale read context.Tasks
TxnManager
and implementGetTxnInfoSchema()
in it. #30695TxnManager.GetTxnInfoSchema()
to get the txn infoschema #30933GetReadTS
andGetForUpdateTS
forTxnManager
#33014EnterNewTxn
andOnStmtStart
to manage txn lifecycle #34390TxnManager
#34533OptimisticTxnContextProvider
for optimistic txn #35130legacy.SimpleTxnContextProvider
#35666session.ExecutePreparedStmt
#35925session_txn
to internal pacakge #36033The text was updated successfully, but these errors were encountered: