[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:
Related
related to SERVER-32323 Update transaction table appropriatel... Closed
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: SERVER-33534 Re-enable non-replication opObserver functionality within transactions.
Branch: master
https://github.com/mongodb/mongo/commit/9056c4d63c3beaae5a5444cb3ad37b61037ae561

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"

https://github.com/mongodb/mongo/blob/3f723beb10caf6bd809b7df05c34b6a97402dadb/src/mongo/db/s/migration_chunk_cloner_source_legacy.cpp#L174

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.

https://github.com/mongodb/mongo/blob/66c537372c0aa54819adb7f72c9eda6cf8750f8e/src/mongo/db/session_catalog.cpp#L161

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 SERVER-32320 we are temporarily disabling the processing of all OpObservers for writes as part of transactions. We'll need to undo that as part of this work as well.

Generated at Thu Feb 08 04:33:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.