[SERVER-24344] Calls to take resource lock unnecessarily check for null Locker on OperationContext Created: 01/Jun/16  Updated: 31/Oct/17  Resolved: 30/Oct/17

Status: Closed
Project: Core Server
Component/s: Internal Code, Storage
Affects Version/s: None
Fix Version/s: 3.6.0-rc2

Type: Task Priority: Trivial - P5
Reporter: Max Hirschhorn Assignee: Xiangyu Yao (Inactive)
Resolution: Done Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Storage 2017-11-13
Participants:

 Description   

std::unique_ptr<Lock::ResourceLock> rLk;
if (!_isRsThreadSafe && opCtx->lockState()) {
    rLk.reset(new Lock::ResourceLock(opCtx->lockState(), resourceIdCatalogMetadata, MODE_X));
}

Prior to https://github.com/mongodb/mongo/commit/12d82c741061da23a442086465322352f157d094#diff-a7d065bc58d47728c995d090e64d88ad, it was possible for an OperationContextNoop to return a nullptr when OperationContext::lockState() was called. This was done to allow use of the KVCatalog class in C++ unit tests against storage engines that don't support document-level concurrency. However, OperationContext::lockState() should never return nullptr after the introduction of the LockerNoop class, so the additional && opCtx->lockState() condition can be removed.



 Comments   
Comment by Githook User [ 30/Oct/17 ]

Author:

{'email': 'xiangyu.yao@mongodb.com', 'name': 'Xiangyu Yao', 'username': 'xy24'}

Message: SERVER-24344 Calls to take resource lock unnecessarily check for null Locker on OperationContext
Branch: master
https://github.com/mongodb/mongo/commit/ec52a8bdc9428508229c81836206679010eb31b5

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