[SERVER-57298] Add statistics for TransactionParticipant to currentOp Created: 28/May/21 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | former-quick-wins | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Replication
|
||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| Description |
|
We should be able to see in $currentOp output the state a transaction is in (started, aborted, prepared, etc), and how long it has been in that state. In particular we should distinguish between "aborting"/"preparing"/"committing" (commands for those states have been issued, but not yet finished) and the normal in-progress state. We should also include why we are waiting in these states (e.g. we may be waiting for RSTL acquisition). We should also add stats counters to FTDC for the aborting/preparing/committing states. |
| Comments |
| Comment by Kaloian Manassiev [ 31/May/21 ] |
|
I believe if there is a wait for RSTL acquisition, it will show-up as a waiting for lock in currentOp and that can't happen without an OpContext. And for stashed transactions, they will not be waiting. Do you think we can also include a dump of all the locks that stashed transactions hold? |