[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:
Related
is related to SERVER-44260 Transaction can conflict with previou... Closed
Assigned Teams:
Replication
Participants:

 Description   

This came out of the work for SERVER-44260. There are two optimizations we can make here:

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?

Generated at Thu Feb 08 05:08:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.