[SERVER-39017] Allow prepared transaction statements to persist in-memory until commit Created: 15/Jan/19 Updated: 29/Oct/23 Resolved: 01/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 4.1.6 |
| Fix Version/s: | 4.1.8 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Sprint: | Sharding 2019-01-28, Sharding 2019-02-11 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
Problem SummaryWe would like to be able to observe all statements on transaction commit. This is so that migrations may take these statements on commit and add them to any current transferMods queue. Currently, for prepared transactions, we discard statements on prepare, and don't persist these statements until commit time. Proposed ApproachWe will have to make changes to the transaction participant in order to persist these statements.
NOTE: We have renamed retrieveOperationsForMigrate() to retrieveOperations(), because we have identified usage of said operations outside of migrate, including here. |
| Comments |
| Comment by Githook User [ 01/Feb/19 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: |
| Comment by Blake Oler [ 17/Jan/19 ] |
|
A note: the transactions team decided to call the onCommit opObserver while an unprepared transaction would still be inProgress. This is so that any exceptions inside the opObserver would allow the transaction to abort instead of committing. As such, we will maintain the current invariant of either inProgress or Prepared for both functions. This will result in no change to current behavior for the prerequisite states. |
| Comment by Judah Schvimer [ 16/Jan/19 ] |
|
lgtm, I defer to Kal on the lifecycle management. |
| Comment by Kaloian Manassiev [ 15/Jan/19 ] |
|
Yeah, I think retrieveCompletedTransactionOperations might be a more appropriate name. I would make retrieveOperations() invariant that the transaction's status is InPrepare or Committed so that callers are not allowed to obtain an intermediate view of the transaction. |
| Comment by Blake Oler [ 15/Jan/19 ] |
The above information will be integrated into the ticket description. kaloian.manassiev do we want to rename the method retrieveOperations() to indicate that the operations are now static? Maybe retrieveCompletedTransactionOperations(). |
| Comment by Kaloian Manassiev [ 15/Jan/19 ] |
|
I have a couple of questions:
What are the lifetime requirements for this method? I.e., it is allowed to only be called with the session checked-out, and only after the transaction participant enters the prepared state, right? With the lifetime above - does it need to return a copy or just reference would work? I think you can just return a reference. The reason why this is better is that this object can be up to 16MB in size. |
| Comment by Blake Oler [ 15/Jan/19 ] |
|
judah.schvimer can I get your LGTM on this approach? It has integrated your comments on the ticket |