[SERVER-34004] Support commitTransaction and abortTransaction commands on secondaries Created: 20/Mar/18 Updated: 29/Oct/23 Resolved: 03/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | William Schultz (Inactive) |
| 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 | ||||||||||||||||||||
| Sprint: | Repl 2018-04-09 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||
| Description |
|
For multi-statement read-only (autocommit:false) transactions, we need to be able to commit/abort them to clean up the associated resources. |
| Comments |
| Comment by Githook User [ 04/Apr/18 ] |
|
Author: {'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}Message: |
| Comment by Githook User [ 03/Apr/18 ] |
|
Author: {'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}Message: |
| Comment by Githook User [ 26/Mar/18 ] |
|
Author: {'email': 'shnhrv@gmail.com', 'name': 'Shane Harvey', 'username': 'ShaneHarvey'}Message: Skip secondary abortTransaction test, blocked on |
| Comment by Spencer Brody (Inactive) [ 21/Mar/18 ] |
|
For 4.0 we could make the wait for write concern on read only transactions a no-op, and only start actually doing writeconcern waiting once we truly support speculative readConcern behavior. |
| Comment by Spencer Brody (Inactive) [ 21/Mar/18 ] |
|
This should also support waiting for write concern, to support waiting for a read done at a 'speculative' readConcern to confirm that the results match the readConcern requested. The initial version will wait for the current last applied optime to become committed. |
| Comment by Andy Schwerin [ 21/Mar/18 ] |
|
The commit command should be able to accept and handle w:majority or w:1 write concern. |