[SERVER-77425] ScopedLocalCatalogWriteFence should not perform logic in rollback handler Created: 24/May/23 Updated: 29/Oct/23 Resolved: 07/Jul/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Henrik Edin | Assignee: | Jordi Serra Torrens |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding EMEA
|
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding EMEA 2023-06-12, Sharding EMEA 2023-06-26, Sharding EMEA 2023-07-10 |
| Participants: |
| Description |
|
Currently, the ScopedLocalCatalogWriteFence refreshes the internal state of the ScopedCollectionAcquisition in a rollback handler. This has two problems: 1. We have an implicit order dependency on how rollback handlers execute. The fence is expecting the local catalog state to have already been rolled back when its own rollback handler executes. The onCommit/onRollback system was not designed to handle dependencies between handlers. 2. When the ScopedCollectionAcquisition is located outside a write conflict retry loop the rollback handling need to actually advance the local catalog state. Depending on what it observes an error condition may occur that is unable to be handled with our regular exception handling due to exceptions thrown from rollback handlers not being allowed. There is currently a workaround that defers the error handling by marking the acquisition as invalid. Ideally, acquisitions should not be scoped outside write conflict retry loops. But due to legacy code, this is not feasible to achieve in the short term. Potential solutions of the above include:
|
| Comments |
| Comment by Githook User [ 07/Jul/23 ] |
|
Author: {'name': 'Jordi Serra Torrens', 'email': 'jordi.serra-torrens@mongodb.com', 'username': 'jordist'}Message: |