[SERVER-38810] Use the Client mutex or the SessionCatalog mutex for concurrency control of the TransactionParticipant Created: 02/Jan/19  Updated: 29/Oct/23  Resolved: 15/Feb/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 4.1.9

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Andy Schwerin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-50400 Migrating session info ignores Config... Closed
related to SERVER-39610 Reformat TransactionParticipant comme... Closed
related to SERVER-39613 Remove kCommittingWithPrepare and kCo... Closed
related to SERVER-39614 Remove inActiveOrKilledMultiDocumentT... Closed
related to SERVER-39615 Replace KillSessionsDuringPrepareDoes... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2019-01-14, Sharding 2019-01-28, Sharding 2019-02-11, Sharding 2019-02-25
Participants:
Linked BF Score: 0

 Description   

This ticket is for implementing the TransactionParticipant concurrency control change to look like this:

  • Changing the state of the TP requires the session to be checked out and the client mutex
  • Observing the state of the TP can be done in on two occasions:
    • Without any locks, if the session is checked out by the reader thread
    • With the session catalog mutex + if currently checked-out by another thread, using the client mutex of that thread.

This rule can also be expressed as: When the Session holding the TransactionParticipant is checked-out, use the OperationContext concurrency rules (i.e., the Client mutex); When it is not checked-out only use the SessionCatalog’s mutex.

Prepare transaction in this case becomes:

  • Check-out session
  • Take client mutex and check for interruption
  • Set the state of the TP to “prepared”

Session invalidation and killAllExpiredTranasctions becomes:

  • In scanSessions, under the session catalog mutex, if session is checked-out currently, take the client mutex, otherwise don’t lock anything else
  • Check if the state is “prepared” and if so, skip this session
  • Check-out for kill any sessions, which weren’t skipped and call abortTransaction on them which must not be allowed to fail

Session invalidation on stepDown and shutDown becomes:

  • In scanSessions, under the session catalog mutex, if session is checked-out currently, take the client mutex, otherwise don’t lock anything else
  • Unconditionally interrupt any operation contexts using this session
  • Check-out for kill all sessions and unconditionally force them to free their resources, which must not be allowed to fail

All TP methods, which require the session to be checked-out will be changed to not accept OperationContext anymore, but to take it from the parent Session object and all methods which expose observable state will be changed to either acquire the client mutex or to accept a WithLock to indicate that they should be run under the client mutex.
In order to reduce the confusion, there will only be two abort-related methods left on the TP:
abortTransaction - used for the regular abort path, direct write to the config.transactions and for killAllExpiredTransactions. Executes the entire abort sequence, updates metrics.
releaseTransactionResources - used for stepDown and shutDown. Releases the transaction’s resources unconditionally and makes the TP look as if it was just created



 Comments   
Comment by Githook User [ 15/Feb/19 ]

Author:

{'name': 'Andy Schwerin', 'email': 'schwerin@mongodb.com', 'username': 'amschwerin'}

Message: SERVER-38810 Use Session's concurrency control rules instead of internal mutexes in TransactionParticipant

This type simplifies and clarifies concurrency control in TransactionParticipant by:

(1) Removing TP's own mutexes and using the Session concurrency control rules,
instead. That is, certain state is only accessible when the Session is checked
out, and requires no further locking. Other state is observable either while
holding the client lock or while having checked out the Session. The latter type
of state is modifiable only when having checked out the session and locked the
client.

(2) Separating the two types of state in (1) into separate sub-structures in
TransactionParticipant, to make it clear who can access what state,

(3) Putting all methods formerly on TransactionParticipant onto new member
classes, TransactionParticipant::Participant and
TransactionParticipant::Observer. The latter can only read the observable state
from (1) above, and the participant may read or modify all of the state.

The two types introduced by (3) are designed to enforce proper concurrency
control by limiting access of their methods to the underlying
TransactionParticipant member variables. The observer type has a private o()
method which its other methods are required by convention to use in order to
obtain read-only access to the Observable state of the
TransactionParticipant. The participant type has the o() method plus an
o(WithLock) method that allows mutation of the state while holding the client
lock, and a p() method which allows reading and writing of the private state
with no other locks. Please see the implementation in
transaction_participant.cpp for examples.

It is worth noting that with this change, locking the Client is not needed often
and never for long, and there is no need for separate mutexes for participant
state and monitoring state.
Branch: master
https://github.com/mongodb/mongo/commit/1d246814a058073f0c26981fff5fe67c16af3593

Comment by Githook User [ 11/Jan/19 ]

Author:

{'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev'}

Message: SERVER-38810 Temporarily do not hold the client lock in ObservableSession in order to avoid deadlock
Branch: master
https://github.com/mongodb/mongo/commit/1bd1b3644378b76e5ff42bb8c6bee8a640e9a866

Comment by Githook User [ 10/Jan/19 ]

Author:

{'username': 'amschwerin', 'email': 'schwerin@mongodb.com', 'name': 'Andy Schwerin'}

Message: SERVER-38810 Simplify correct usage of locking in Session/SessionCatalog.

This patch introduces two new types for gaining access to sessions in
the session catalog, based on the context of the access. It leaves a
third way to access sessions, which is via
OperationContextSession::get().

The new types are ObservableSession and SessionToKill. With this
change, a thread may access a session in one of three ways:

(1) by binding the session to an OperationContext for regular use, by
instantiation of OperationContextSession or
MongoDOperationContextSession, as before.

(2) In the callback passed to SessionCatalog::scanSessions, in which
case the callback is passed an ObservableSession that represents
looking at a Session while the SessionCatalog mutex is locked and
while the bound OperationContext's client mutex is held, if the
session is currently checked out via methods (1) or (3).

(3) By calling SessionCatalog::checkOutSessionForKill, which returns a
KillableSession. This is used for cleaning a session up after it is
marked for kill.

This patch eliminates Session::_mutex, which is no longer required, as
the SessionCatalog::_mutex and the Client provide all necessary mutual
exclusion for the Session type itself.
Branch: master
https://github.com/mongodb/mongo/commit/facdcf14cfec192876a373fc49163769215327d8

Generated at Thu Feb 08 04:50:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.