While MongoDB's storage API historically allowed for composing smaller write units of work into bigger ones by nesting WriteUnitOfWork RAII types, since the addition of user-level timestamping, not all transactions are safely composable in this way. Consider the following example:
# A single MongoDB crud transaction will: # 1) Write A # 2) SetTimestamp T # 3) Write B # Intending for timestamp T to apply to both A and B. Concatenating # two crud operations gives: # 1) Write A # 2) SetTimestamp T # 3) Write B # 4) Write C # 5) SetTimestamp T+1 # 6) Write D # Intending for timestamp T to apply to write's A and B, and T+1 # to apply to C and D. But is that what happens? # # It turns out the writes to B and C are visible at T, however A # and D are not. | Writer | Reader | |----------------------+------------------| | Begin | | | Write A 1 | | | Timestamp :commit 10 | | | Write B 1 | | | Write C 1 | | | Timestamp :commit 20 | | | Write D 1 | | | Commit | | | | Begin :readAt 15 | | | Read A | | | Read B | | | Read C | | | Read D |
The invariant that I think makes sense to suss out the typical pattern that goes bad (said two different ways):
- If a transaction sets multiple timestamps, the first timestamp must be set prior to any writes
- If a transaction writes a document before setting a timestamp, it must not set multiple timestamps.
- is duplicated by
-
SERVER-45354 In renameCollectionAcrossDBs, writes to temporary collection must use correct timestamps
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
WT-6388 Fix-up out-of-order updates in the history store
-
- Closed
-
-
-
- Investigating
-
- related to
-
-
- Closed
-
-
-
- Closed
-
-
SERVER-72723 support rollback for multi-oplog batched writes
-
- Closed
-
-
-
- Closed
-