[SERVER-50349] Requests for writable Collection should be under WUOW Created: 18/Aug/20  Updated: 29/Oct/23  Resolved: 15/Sep/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.8.0

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Henrik Edin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-57324 dropDatabase should not modify Collec... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2020-09-07, Execution Team 2020-09-21
Participants:

 Description   

We need to be under a WUOW when requesting a writable Collection for metadata updates under MODE_X lock.

Note that simple insert, update, delete of documents under MODE_IX should not require this.



 Comments   
Comment by Githook User [ 15/Sep/20 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-50349 Getting a writable collection now requires the caller to be inside a WUOW by default

There are three modes when accessing a writable Collection:

  • Managed in WUOW (default)
  • Unmanaged (users need to commit/rollback)
  • Inplace that provides direct access to the Collection in the catalog. (Users need to ensure there's no concurrent operations going on)

Added a helper RAII type CollectionWriter that abstract the three modes above and also provides abstraction on different methods of accessing Collections (AutoGetCollection or manual lookups).

Writable Collection is aquired lazily when needed (usually inside a WUOW).
Branch: master
https://github.com/mongodb/mongo/commit/accc7e7cd7e7a984347361d03ee76514c4a54163

Comment by Henrik Edin [ 31/Aug/20 ]

daniel.gottlieb Yes of course!

This is just referring to SERVER-50317 where insert, update and delete can now be performed on a const-collection (but still under a WUOW of course)

You can do lookupCollectionByUUID (that will return a const-collection soon) without a WUOW, but any subsequent write op still needs a WUOW.

I do not anticipate any risk with code like you show, as an MODE_IX lock is still being held so there can't be another holder of a MODE_X lock that can make the Collection pointer stale.

This is just prerequisite work for SERVER-50145 where a new Collection instance will be created for MODE_X writers that do metadata changes to the collection. We need to be in a WUOW in that case so any changes can be rolled back.

Hope that makes it clearer.

Comment by Daniel Gottlieb (Inactive) [ 19/Aug/20 ]

Note that simple insert, update, delete of documents under MODE_IX should not require this.

Certainly one still needs a WUOW for doing the insert/update/delete? Are there any anticipated risks with code that does:

AutoGetCollection coll(opCtx, "foo.bar", MODE_IX);
writeConflictRetry {
  WUOW wuow(opCtx);
  coll->insert(doc);
  wuow.commit();
}

Specifically, if the collection pointer is stale[1] can that prevent a write from succeeding? Will those failures only ever be uasserts? Or is it plausible those could be WCE landing the code in an infinite loop because the collection is never refreshed?

[1] In most cases, the locks/collection objects are acquired prior to a storage engine snapshot being allocated (which I think proves the collection object cannot be stale). But that's not necessarily true with multi-statement transactions (and maybe some other kinds of writes that read at a no-holes point?)

Generated at Thu Feb 08 05:22:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.