[SERVER-54534] No need to wait for writeConcern on aborting a multi-document transaction Created: 12/Feb/21 Updated: 29/Oct/23 Resolved: 16/Feb/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Lingzhi Deng | Assignee: | Lingzhi Deng |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||
| Sprint: | Repl 2021-02-22 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
If a transaction aborts due to reasons other than an explicit abortTransaction command (e.g. writeConflict errors), we could still hit this which would call setLastOpToSystemLastOpTime and waitForWriteConcern unnecessarily. There is also a weird behavior where if the same connection is used outside of transaction, abortTransction would also wait for writeConcern for the lastOp set by the same connection in previous writes done outside of the transaction (see this test). This is because wasGlobalLockTakenForWrite would always be true when aborting a transaction (either through abortTransction command or due to transaction errors). |
| Comments |
| Comment by Githook User [ 16/Feb/21 ] |
|
Author: {'name': 'Lingzhi Deng', 'email': 'lingzhi.deng@mongodb.com', 'username': 'ldennis'}Message: |