[SERVER-45430] Optimize the way a transaction waits for the previous transaction's table update to be durable Created: 09/Jan/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Pavithra Vetriselvan | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ShardedTxn:FutureOptimizations | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
This came out of the work for 1. The bug should only apply to transactions using readConcern: snapshot. We should check this before calling waitForAllEarlierOplogWritesToBeVisible(). 2. Ideally, we could pass an optional timestamp parameter into waitForAllEarlierOplogWritesToBeVisible() that specifies the timestamp the all_durable must reach before returning. This would be a weaker guarantee than waiting until the last oplog entry write is durable, but seems like a reasonable extension of this method. The TransactionParticipant can keep track of the timestamp of the last transaction table write (we only care about prepared commits and prepared aborts), which would be passed into waitForAllEarlierOplogWritesToBeVisible(). |
| Comments |
| Comment by Eric Milkie [ 10/Jan/20 ] |
|
Seems reasonable to me. |
| Comment by Pavithra Vetriselvan [ 09/Jan/20 ] |
|
milkie Do the changes to waitForAllEarlierOplogWritesToBeVisible() sound reasonable? |