Lock Tree
On the Lock Tree screen, you can view sessions that are waiting on each other due to locks in a tree form. It shows which session is holding a resource (holder) and which session is waiting for it (waiter) as a parent-child relationship, helping you quickly find the session that caused a deadlock.
Locks and the Lock Tree
Simply put, a lock is a locking mechanism that prevents the same data from being changed simultaneously. While one session is modifying data, other sessions must wait. As the number of waiting sessions grows and they become entangled with each other, a deadlock occurs. The Lock Tree lays out these wait relationships in a tree shape so you can find the session holding the resource (the cause) at the very top.
Basic Screen Guide
At the top of the screen, select an instance and a database. First, select the point in time when a lock wait occurred in the Lock Wait Sessions chart, and you can then view the Lock Tree and Total Locks at that point. It highlights locks that have persisted for several minutes or more, so you can quickly find long-held locks.
| Area | Description |
|---|---|
| Lock Wait Sessions | A chart of lock wait session counts by time period. Select a point in time to query |
| Lock Tree | Displays the lock wait relationships at the selected point in time as a tree |
| Total Locks | The total number of locks at the selected point in time |
Column Guide
The session holding a resource (holder) and the session waiting (waiter) are displayed with the following columns.
| Column | Description |
|---|---|
instance | The node where the session is running |
node_id | Node identifier |
session_id | Session ID |
db | The database in use |
user | Connected user |
tx_state | Transaction state |
lock_type | Lock type |
row_locks | Number of row locks |
partition_locks | Number of partition locks |
activity | Activity name |
raw_task | The raw text of the SQL being executed |
sql_param | SQL parameters |
command | The type of command being executed |
elapsed_time_ms | Execution time (milliseconds) |
One point that can be confusing here is how sessions are identified. MySQL identifies a session by a single session ID, but because SingleStore is a distributed environment, it uses the node identifier and the session ID together (node_id + session_id) as the matching key. This is because even the same session ID refers to a different session if the node differs. row_locks and partition_locks distinguish whether a lock is at the row level or the partition level in a distributed environment.
Resolving Locks
After identifying the causal session (holder), you can stop that session if necessary. For how to stop a session, refer to the Session History and Instance Monitoring documents.
Analyzing with AI
Click the WhaTap AI button on the screen to open the WhaTap AI chat window, where the queried screen data is summarized and the analysis result is shown as a conversation. After reading the result, you can continue with follow-up questions in the same conversation.
-
The data used for the analysis is three sets: the trend for the whole query range, the 30-minute interval aggregation, and the lock tree snapshot at the selected point in time.
-
The analysis target is the data queried on the screen. If you change the query conditions and analyze again, the analysis is based on the changed data.
-
The conversation history is recorded in the
AI Analysis - {screen name}format.