[SERVER-33534] Ensure that OpObservers function properly for writes as part of transactions Created: 27/Feb/18 Updated: 29/Oct/23 Resolved: 13/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Matthew Russotto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2018-04-09, Repl 2018-04-23 | ||||||||
| Participants: | |||||||||
| Description |
|
We need to make sure that all systems that use OpObservers to maintain in-memory state are prepared for their OpObserver to fire long before the operation is committed. Most of them should already be doing any work they need to undo in an onCommit hook, but some of them make changes speculatively then register onRollback handlers instead. |
| Comments |
| Comment by Githook User [ 13/Apr/18 ] |
|
Author: {'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}Message: |
| Comment by Matthew Russotto [ 05/Apr/18 ] |
|
The work done by onUpdate in opObservers is AuthorizationManager::logOp(), which works on admin.system.roles, admin.system.users, admin.system.version. There may be an issue when updating admin.system.users; the user cache is invalidated immediately instead of on commit. However, since it is not legal to modify system collections in transactions, I will not fix this as part of this ticket CollectionShardingState::onUpdateOp(). This correctly does work at commit time; however, it expects to have an opTime and if it does not, it may not call "sessionSource->notifyNewWriteOpTime" I will fix this by arranging for the CollectionShardingState to be notified on commit as well as on update. Scope:storedFuncMod(): This affects the system.js collection in any database. It correctly does work on commit, but this means changes to the system.js collection will not be affected within the uncommitted transaction context. Because changes to collections in system namespaces are not supported within a transaction, I will not fix this in this ticket. DurableViewCatalog::onExternalChange: Similar to Scope::storedFuncMod(), only with system.views collection. Not supported. FeatureCompatibilityVersion::onInsertOrUpdate(): admin.system.version namespace. It is definitely not supported to update feature compatibility transactionally. SessionCatalog::invalidateSessions: Affects the config.transactions namespace. Writing that within a transaction should not be supported, and in fact already uasserts. onDelete() hits the same set of operations except CollectionShardingState::onDeleteOp() onInsert() same except CollectionShardingState::onInsertOp() |
| Comment by Spencer Brody (Inactive) [ 27/Feb/18 ] |
|
As part of |