[SERVER-41780] prepareTransaction doesn't always wait for write concern on retries Created: 14/Jun/19  Updated: 29/Oct/23  Resolved: 25/Jun/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.2.0-rc2, 4.3.1

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-45400 Reduce OplogFetcher getMore awaitData... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2
Sprint: Repl 2019-07-01
Participants:
Linked BF Score: 21

 Description   

We no longer wait for write concern on the client lastOp no matter what as of SERVER-33727. We only do so if the client explicitly set the lastOp forward. Retrying prepareTransaction only sets the lastOp if it is less than the prepareOpTime. We really need to call setLastOpToSystemLastOpTime always and then also set it to the prepareOpTime if that's still greater. That will make sure prepare retries always wait for write concern.



 Comments   
Comment by Githook User [ 25/Jun/19 ]

Author:

{'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}

Message: SERVER-41780 always wait for write concern on prepareTransaction retries

(cherry picked from commit add3f7ba3cca63f4ffbb8a5712f7e20b17f3cf28)
Branch: v4.2
https://github.com/mongodb/mongo/commit/4dba23de42733d08df9829e93e9d726fdf72cd59

Comment by Githook User [ 25/Jun/19 ]

Author:

{'name': 'Judah Schvimer', 'username': 'judahschvimer', 'email': 'judah@mongodb.com'}

Message: SERVER-41780 always wait for write concern on prepareTransaction retries
Branch: master
https://github.com/mongodb/mongo/commit/add3f7ba3cca63f4ffbb8a5712f7e20b17f3cf28

Comment by Judah Schvimer [ 18/Jun/19 ]

It looks like this is only a problem for prepareTransaction. I'm improving our testing a bit, especially around transactions to ensure that.

Comment by Judah Schvimer [ 17/Jun/19 ]

Calling setLastOp or setLastOpToSystemLastOpTime will guarantee we wait for write concern no matter what. It is only a problem if we never call either. I will audit callers of those two to make sure we never have any surrounding if statements like in prepare elsewhere.

Comment by Esha Maharishi (Inactive) [ 17/Jun/19 ]

Note, what if the client's lastOp somehow is equal to the system last OpTime? Will calling setLastOpToSystemLastOpTime still guarantee that the server waits for writeConcern?

Generated at Thu Feb 08 04:58:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.