[SERVER-66340] Improve distributed transaction commit locking behavior Created: 10/May/22 Updated: 14/Dec/23 Resolved: 14/Dec/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Gregory Noma | Assignee: | Josef Ahmad |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | car-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||
| Sprint: | CAR Team 2023-12-25 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||||||||||
| Description |
|
In a distributed transaction, when the coordinator writes its commit decision, it takes global/db/collection locks to do so while the participant is also still holding the global lock. This can cause issues when combined with operations that take strong global locks, as seen in |
| Comments |
| Comment by Githook User [ 13/Dec/23 ] |
|
Author: {'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}Message: This barrier resolves a class of deadlocks involving an uncommitted transaction in the The FeatureCompatibilityVersion lock was initially introduced to address this issue One (benign) behavioural change is that prepared transactions that commit while a global GitOrigin-RevId: 6517ac7482c0aa6da26af1b530bd5755737d6d1e |
| Comment by Geert Bosch [ 25/Aug/22 ] |
|
I chatted with Max, and we agree that this ticket is not ready for work as written, but rather indicates that there's some larger rethink/remodel that is necessary to be able to remove the current workaround. I'l put this on the storage execution backlog for now to see if there is a project that we can make this part of. |
| Comment by Max Hirschhorn [ 25/Aug/22 ] |
|
geert.bosch@mongodb.com, I'd like to propose we close this ticket without making any changes and leave the new resourceIdFeatureCompatibilityVersion resource as-is. I think attempting to have the TransactionCoordinator and TransactionParticipant share their TxnResources (read: LockManager locks) is a challenging undertaking and isn't fully sufficient as an alternative for I feel like approaching the TransactionCoordinator differently ties into approaching the threading and Client models differently for the whole server. Are you comfortable with leaving things as-is? |