[DOCS-11516] document lockInfo command Created: 30/Mar/18  Updated: 13/Nov/23  Due: 22/May/20  Resolved: 18/May/20

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 4.4.0-rc4, 4.7.0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Improvement Priority: Major - P3
Reporter: Geert Bosch Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-46634 LockInfo results missing a layer of h... Closed
Documented
documents SERVER-46360 Hang analyzer json logging improvement Closed
Duplicate
duplicates DOCS-8989 Add command to dump lock manager state Closed
Related
related to DOCS-7765 Flesh out documentation for 'external... Closed
is related to SERVER-39858 Provide a command to list all locks Closed
Participants:
Days since reply: 3 years, 38 weeks, 2 days ago
Epic Link: DOCS: 4.4 Server Release Work

 Description   

With multi-statement transaction support, MongoDB will more often hold locks for an extended period of time. As it can be hard for a user to figure out what causes the blocking, it may be useful for them to obtain the list of locks held, and which operations hold these locks.

The lockInfo command gives this information, but currently is a well-kept secret.
Documenting the command might help change that.



 Comments   
Comment by Githook User [ 18/May/20 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-11516: lockInfo
Branch: v4.2
https://github.com/mongodb/docs/commit/930edc59da95bb624f669f6feac481a88c661408

Comment by Githook User [ 18/May/20 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-11516: lockInfo
Branch: master
https://github.com/mongodb/docs/commit/1d1176d2fdf97508c15ce5d8646a1dff81aebc84

Comment by Billy Donahue [ 05/Mar/20 ]

created SERVER-46634 and marked it as a dependency of this ticket.

Comment by Geert Bosch [ 05/Mar/20 ]

Could you file a SERVER ticket for that? Thanks!

Comment by Billy Donahue [ 05/Mar/20 ]

We should fix the result layout before making it more widely published and/or documenting it.

Comment by Billy Donahue [ 05/Mar/20 ]

We should fix the layout of the result as well.
It's currently

 
      // add an element to result object:
      //     "lockInfo": [
      //         // for each nonempty bucket in LockManager, add a suboject.
      //         {
      //             "resourceId": <string>,
      //             "granted": [ {}, ... ],  // array of locks
      //             "pending": [ {}, ... ],  // array of locks
      //
      //             // repeated keys are used to represent each lock in a bucket
      //             "resourceId": <string>,
      //             "granted": [ {}, ... ],  // array of locks
      //             "pending": [ {}, ... ],  // array of locks
      //
      //             ...
      //         },
      //         ...
      //     ]

It's obvious we're missing a layer of hierarchy in the structure.

The group of repeating keys (resourceId,granted,pending) should instead be the keys of a subobject created for each lock in the bucket.

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