| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
on mongod
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o getCurrentMetadataIfKnown - which returns the current filtering
metadata if any is available
o getMetadataForOperation - which returns the metadata which is required
by the current opertion, based on the OperationShardingState
o getCurrentMetadata - which returns the currently available filtering
metadata (or UNSHARDED if not known)
This is in preparation for making
getMetadataForOperation/getCurrentMetadata throw
StaleShardVersion exception if the metadata has not been loaded yet.
|
|
|
|
|
|
|
|
| |
Before doing so, refresh the catalog cache to make sure the mongos
serving the request is at least somewhat up to date. Additionally,
communicate the epoch used to choose the uniqueKey from mongos to the
shards, and raise an error from the shards and terminate the
aggregation if the epoch of the targeted collection ever changes.
|
| |
|
| |
|
| |
|
|
Refactor process interface system to use shim to allow for separate factories for embedded and mongod.
|