[SERVER-37516] Providing readConcern on second transaction statement can corrupt transaction Created: 08/Oct/18 Updated: 09/Nov/18 Resolved: 09/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 4.0.3, 4.1.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Siyuan Zhou |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Repl 2018-10-22, Repl 2018-11-05, Repl 2018-11-19 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
We do not allow read concern on transaction statements after the first one. However, we do not check for this until unstashTransactionResources(), which occurs after we wait for read concern. This is problematic, since providing a read concern a subsequent statement does not abort the transaction, but waiting for read concern has side effects, such as setting the read timestamp of the transaction, which is used for the writeConcern wait on commitTransaction. This means you could end up with a corrupted transaction. This is not a major issue, since drivers and mongos will not send readConcern on subsequent transaction statements. |
| Comments |
| Comment by Tess Avitabile (Inactive) [ 09/Nov/18 ] |
|
Yes, I think the bug went away with your change. |
| Comment by Siyuan Zhou [ 09/Nov/18 ] |
|
With pushing down starting transaction to before command execution in If a user specifies the read concern and startTransaction for the second command, we'll still find it later when starting the transaction as described above. However, it shouldn't have any side-effect and should be rare since drivers and mongos won't do that. tess.avitabile, do you think your concerns in the description are addressed by |