-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 6.2.0-rc1, 6.3.0-rc0
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
35
After callers of the synchronous internal transaction API are interrupted, the cancellation token of the transaction is canceled and the caller waits for the transaction to complete uninterruptibly to guarantee the callback provided to the API has completed and its referenced variables are still in scope. This relies on the assumption that cancelling the token for the transaction will soon complete the transaction.
SERVER-70247 fixed an issue where cancelling the transaction API will prevent the API from best effort aborting its transaction, leading to wasted resources. The fix made the best effort abort always use an uncancelable cancellation token. The API still forces callers to wait for the best effort abort to complete before returning though, so if the abort hangs, the caller will hang as well.
This can trigger a deadlock if the caller of the API holds a resource like a SessionCatalog session for a different session than the transaction uses (e.g. if the caller uses the transaction API from an AlternativeClientRegion) that can prevent a stepdown from completing which may block the abort command when it tries to take the RSTL before running.
A possible fix is to refactor the API so it does not block the caller waiting for the best effort abort.
- is related to
-
SERVER-72287 Make transaction API wait for best effort abort if it hasn't been interrupted
- Closed
-
SERVER-72413 Split may return an error when it is actually committed
- Closed
- related to
-
SERVER-70247 SyncTransactionWithRetries used with SEPTransactionClient can leave transactions open when runNoThrow opCtx gets cancelled
- Closed