| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
produced by:
hits="$(git grep -n MONGO_DISALLOW_COPYING | cut -d: -f1 )"
for f in "$hits"; do
sed -i.orig '
s/^\( *\)MONGO_DISALLOW_COPYING(\(.*\));/\1\2(const \2\&) = delete;\n\1\2\& operator=(const \2\&) = delete;/;
' $f
done
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Remove leading comments that are just stating the filename.
Move any file-level comments below the copyright banner.
Remove leading blank lines.
|
|
|
|
| |
order to avoid deadlock
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
With this change there are no callers which modify the session state
without having checked it out first.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
OperationContextSession
This simplifies the behaviour of the class and moves all the check-out
decision taking to happen in the only consumer - the endpoint.
Also renames OperationContextSessionMongoD to MongoDOperationContextSession
in order to be in sync with the naming nomenclature of SessionCatalog and
MongoDSessionCatalog.
|
|
|
|
| |
expect ConflictingOperationInProgress
|
|
|
|
|
|
| |
retryable_writes_direct_write_to_config_transactions.js expect ConflictingOperationInProgress"
This reverts commit 2f640ed748b861a242b3ad153e821f6b459b2511.
|
|
|
|
| |
expect ConflictingOperationInProgress
|
|
|
|
| |
Session/TransactionParticipant object
|
|
|
|
|
|
|
|
| |
Session
The session's check-out state is currently duplicated between
SessionCatalog's internal container structure and the Session class.
This change moves it all to be under Session.
|
|
|
|
|
|
|
|
|
|
|
| |
transactions on step down
This change reverts the following commits:
* SERVER-35870 Allow stepdown to work with prepared transactions (f96903979ac329a760e7b6f1bb5d8695d3daf2a7)
* SERVER-36913 Add functionality to LockManager for repl state transitions with prepared transactions (e65ff57e108ed69c46cc0b0ccbdd675663de2469)
* SERVER-35870 Allow more than one thread to block Session checkout at a time (9406af079a894bae80fbbec4703b04974bf84476)
* SERVER-35870 Add functionality to prevent Session checkouts & wait for all Sessions to be checked in (c6d90316d6b694e12426274c713a4a078e004fc5)
|
|
|
|
| |
LogicalSessionId when tracking
|
| |
|
| |
|
|
|
|
|
|
|
| |
Session into TransactionParticipant
This change leaves the Session class to be a plain decorable structure
only used for serialization of operations on the same logical session.
|
| |
|
|
|
|
| |
Sessions to be checked in
|
| |
|
| |
|
|
|
|
| |
databases within transactions
|
|
|
|
|
|
|
|
|
|
|
| |
support
for 'startTransaction' argument
This patch requires all operations that are part of a multi-statement transaction to
specify an autocommit=false command argument. It also adds the 'startTransaction'
command argument, which when specified as 'true' indicates that a command is
the beginning of a multi-statement transaction.
|
|
|
|
| |
killCursors
|
|
|
|
| |
DBDirectClient explicitly instead
|
| |
|
| |
|
| |
|
|
|
|
| |
transaction resources
|
| |
|
| |
|
| |
|
|
|
|
| |
`config.transactions`
|
|
|
|
|
|
| |
to `config.transactions`"
This reverts commit c8cb9cc374af47f862d81e52ad4bc33d96239ef0.
|
|
|
|
| |
`config.transactions`
|
|
|
|
|
| |
This makes the check for whether a statement executed take O(1) time
instead of O(size of the batch).
|
| |
|
|
|
|
|
|
| |
This change exposes a single 'onWriteCompleted' method on the Session
object, which hides all the concurrency control and the session cache
maintenance.
|
| |
|
|
|
|
| |
This reverts commit e00c6d29996ba52b5a77a072d1c5c555f62b8534.
|
| |
|
|
|
|
| |
refetch
|
| |
|
| |
|
|
|
|
| |
OperationContext
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inclusion of a sha256 digest of the full username to the logical session
id (in addition to the current guid) is necessary to fully disambiguate
logical sessions in degraded clusters (when the authoritative record for
a session is unreachable).
Semantics for the uid are as follows:
session creation via startSession()
* Sessions can only be created with one, and only one, user authenticated
* The composite key is created from a guid created on the spot, as well
as the digest of the currently auth'd username
* Only the session guid is returned to the user
* This prevents outside users from attempting to send back a value
we'd have to check. It's preferable to decorate the guid with the
user digest per command, rather than having to check a value the user
might send.
session use for a command
* Sessions are passed via the lsid top level field in any command
* Sessions are only meaningful for commands which requireAuth. For
sessions which don't require auth, we strip session information from the
command at parse time
* Session ids are passed as an object, which can optionally include the
username digest
* It is illegal to pass the username digest unless the currently
auth'd user has the impersonate privilege (the __system user does).
This enables sessions on shard servers via mongos
|
| |
|
|
Also makes the session state available on the OperationContext.
|