[SERVER-37179] Wait for specified write concern whenever commitTransaction returns a NoSuchTransaction error Created: 17/Sep/18 Updated: 29/Oct/23 Resolved: 13/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.7, 4.1.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Siyuan Zhou |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2018-10-22, Repl 2018-11-05, Repl 2018-11-19 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 11 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
If a transaction commits locally against a primary, but that primary goes down without replicating the commit, then if the commitTransaction command is retried against the new primary it will error with NoSuchTransaction. Generally a NoSuchTransaction error in this case indicates that the transaction either aborted or rolled back, and thus it would be safe to retry the entire transaction over. If, however, the writeConcern times out in this case then its possible that the original primary could be re-elected without rolling back the txn commit, and thus the transaction could wind up surviving after all. |
| Comments |
| Comment by Githook User [ 05/Mar/19 ] |
|
Author: {'name': 'Siyuan Zhou', 'username': 'visualzhou', 'email': 'siyuan.zhou@mongodb.com'}Message: (cherry picked from commit 6394bfafd5c42bfeb01b6686498d7fff697d9480) |
| Comment by Githook User [ 04/Mar/19 ] |
|
Author: {'name': 'Siyuan Zhou', 'username': 'visualzhou', 'email': 'siyuan.zhou@mongodb.com'}Message: This patch redid 248601a647 and 4fb38d9c10 from master on v4.0 branch. Transaction will begin or continue after waiting for read concern. If |
| Comment by Githook User [ 13/Nov/18 ] |
|
Author: {'name': 'Siyuan Zhou', 'email': 'siyuan.zhou@mongodb.com', 'username': 'visualzhou'}Message: |
| Comment by Githook User [ 08/Nov/18 ] |
|
Author: {'name': 'Siyuan Zhou', 'email': 'siyuan.zhou@mongodb.com', 'username': 'visualzhou'}Message: Transaction will begin or continue after waiting for read concern. If |
| Comment by Githook User [ 25/Oct/18 ] |
|
Author: {'name': 'Siyuan Zhou', 'email': 'siyuan.zhou@mongodb.com', 'username': 'visualzhou'}Message: |
| Comment by Siyuan Zhou [ 10/Oct/18 ] |
|
According to the design of "Single Replica Set Transactions":
Also from the documentation:
There are two problems in this ticket: 1) we don't wait for write concern if NoSuchTransaction is returned. 2) we shouldn't attach transient transaction error label if the given write concern fails. I remove the mention of "majority" in the title. |
| Comment by Judah Schvimer [ 10/Oct/18 ] |
|
What is the expected behavior if the writeconcern is not majority? |
| Comment by Janna Golden [ 09/Oct/18 ] |
|
I'm seeing the following scenario in testing against failover: |
| Comment by Spencer Brody (Inactive) [ 21/Sep/18 ] |
|
Really the only time commitTransaction should attach a TransientTransactionError is specifically the case where it fails with NoSuchTransaction AND the writeConcern:majority wait is successful. |