[SERVER-65106] Don't perform eviction after prepared transaction commits or rolls-back Created: 31/Mar/22 Updated: 29/Oct/23 Resolved: 27/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Louis Williams |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Sprint: | Execution Team 2023-03-06 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 10 | ||||||||||||||||||||||||
| Description |
|
This is an alternative solution to both When MongoDB encounters a prepare conflict in WiredTiger, we wait until an active MongoDB WriteUnitOfWork commits or aborts. There is a deadlock caused by this approach that can be described as follows:
This is only a bug in a system with one prepared transaction, since any transactions committing or aborting would wake the reader. We want to break this deadlock in MongoDB by requesting to WiredTiger that the operation not perform eviction after it rolls back or commits. |
| Comments |
| Comment by Louis Williams [ 27/Feb/23 ] |
|
This implements the solution proposed in Even though this problem exists on older branches, I am choosing not to request backports because this problem has only ever been reproduced in abnormal WT cache configurations. |
| Comment by Githook User [ 24/Feb/23 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |
| Comment by Connie Chen [ 13/Feb/23 ] |
|
We think the simplest solution is to periodically wake up and see if a transaction has been committed |
| Comment by Louis Williams [ 13/Apr/22 ] |
|
keith.smith@mongodb.com, yes, the reader has an active transaction. While I think the answer is "yes", we could reset the cursor while waiting, it would require some significant changes to our code. We instrument waiting for prepare conflicts in almost every cursor API call we make to WiredTiger. We would probably need to expand the scope of each retry loop to include the part that positions the cursor. And I imagine we would have to carefully consider each loop to ensure each sequence is safely retryable. |
| Comment by Keith Smith [ 12/Apr/22 ] |
|
Step two of the scenario on the description says:
Just to clarify, does the reader here have an active transaction while it is waiting? If so, is there other transaction state that may be in play here (i.e., updates from previous operations)? If the read cursor is really the only WT resource the reader has, could it just reset the cursor before sleeping? |
| Comment by Chenhao Qu [ 31/Mar/22 ] |
|
louis.williams I don't think there is a way to do that at the moment. But I think we can add a configuration in transaction commit to achieve that. |
| Comment by Louis Williams [ 31/Mar/22 ] |
|
chenhao.qu, agorrod, etienne.petrel: Is there any way to ask WiredTiger that a transaction not perform eviction when it commits? We currently use "operation_timeout_ms" in certain cases of rollback, but I don’t believe this works for commit_transaction. I ask because |