Processing of a Priority Session
When there are a large number of connections and heavy load, transactions that obtain a lock can be processed first. The original processing logic is that after a readable event occurs on such connections, the connections are put into the priority queue by the thread group and wait to be processed by an idle worker thread. The logic is further optimized. Instead of returning the worker thread occupied by the session that has entered the priority queue to the thread pool, the session continues to exclusively occupy this worker thread and processes the service logic. This is similar to the one thread for one connection mode. In this way, the exclusively occupied worker thread is used to process nothing else but all subsequent statements of the priority connection unless the connection changes to a common one, for example, when the connection transaction ends and the lock is released. Figure 1 illustrates the logic for determining whether a session connection is prioritized.
Table 1 describes the steps in the figure.
|
Step |
Description |
|---|---|
|
① |
When a new connection is established, the worker thread processes the login verification logic. The connection lifecycle starts. |
|
② |
After the login verification of the new connection is complete, the system checks whether this session has a high priority. |
|
③ |
If it is a management connection on the Admin port, the worker thread is exclusively occupied. This prevents the connection from entering the waiting queue. |
|
④ |
If it is a high-priority session, after processing the connection, the worker thread continues to be occupied and waits to execute the next SQL statement in step 6. |
|
⑤ |
If it is a common session, the connection identifier of the session is added to the epoll_wait queue of the thread group. The status of the worker thread changes to idle, and the worker thread is returned to its thread group. |
|
⑥ |
If a network readable event (an SQL statement arrives) is triggered in epoll_wait or a session exclusively occupies a worker thread, the worker thread waits for the arrival of the SQL statement. |
|
⑦ |
The worker thread waits for, receives, and executes the SQL statement. If the execution result is normal and the connection is not ended, step 3 is performed again to determine the session priority. |
|
⑧ |
The login verification fails, and the connection ends. |
|
⑨ |
The connection ends if an error occurs when the worker thread waits for or executes an SQL statement or if the session ends and exits. |
