Project: OceanBase (App Definition and Development / Database)
File: ob_wait_event_desc.md

all DTL channels are managed by DTL channel manager using a hash map. Threads enter "dtl channel mgr hashmap lock wait" when concurrently insert/delete/get/iterate the hashmap. DTL channels are organized as a list. Lock the list when new channel is added or removed. Unused DTL cached buffer info structure is organized as a free list. Lock the list when buffer is allocated from the free list or returned to the free list. pl debug let you can debug the following program units (PL/SQL programs): anonymous blocks, packages, procedures, functions, and triggers. Threads enter "pl debug lock wait" when concurrently debug pl/sql. when debug a pl , use sys breakpoint to pause the PL/SQL programs. Threads enter "pl sys breakpoint lock wait" when concurrently debug the pl/sql program. dbmsjob create a job task to execute user-defined job. Threads enter "dbmsjob task lock wait" when concurrently when run/add/execute immediate a job. dbmsjob use dbmsjob master to schedule all tasks. Threads enter "dbms_job master lock wait" when concurrently when register a job to master. There is a concurrency problem between the regularly triggered ps cache evict task and the manually triggered flush ps cache evict task. There is also a concurrency problem between the flush ps cache evict tasks triggered at the same time in different sessions. The same ps statement may be added to the closed list by different ps cache evict tasks at the same time. The mutex is used here to make all flush ps cache evict tasks execute serially Shared hash join algorithm need to sync multiple threads when building the shared hash table. A mutex is used to sync all threads. This lock is used to protect the mutex. Shared hash join algorithm need to sync multiple threads when building the shared hash table. A mutex is used to sync all threads. SQL Work Area Profile maintain a list of memory work area profiles, which is shared by all SQL threads. Use this lock to provide concurrency safety. SQL Work Area Stat is maintained as a hash table. which is accessed by all SQL threads. Use this lock to provide concurrency safety. SQL Memory Manager is a global object shared by all SQL threads. Use this lock to provide concurrency safety for its internal data structures such as global memory bounds. Loaddata function loads data in parallel RPCs. It use this lock to serialize multi async loaddata RPC callbacks. When dynamic sampling is used for parallel query with range reshuffle, threads wait when concurrent sampling message returned to the coordinator. SQL granule iterator task queue let parallel query tasks get their tasks from a shared pool. threads wait when threads concurrently obtaining next task from the queue. DTL receive channel provider is accessed by all PX tasks in a DFO. parallel target value is updated by concurrent parallel queries. Threads wait here when they enter or exit the query process simultaneously. px worker link its stat into the virtual view `allvirtualpxworkerstat` when the worker is running. This lock provide concurrency safety. At most one query can run in a session in the same time. session query lock guarante this. Data in a session can be accessed by multiple threads at the same time. For example, when a query is updating session thread data, V$ACTIVESESSIONHISTORY may also access it at the same time. Idle session are cached in a session pool. This lock is used to prevent creating session pool

A sequence value cache is access by multiple threads when allocating sequence value. This lock prevent deleting sequence cache when other threads reading the cache. Lock for inner connection Lock for tenant resource manager Thread local cache free list lock dbmsschedler create a job task to execute user-defined job. Threads enter "dbmsschedler task lock wait" when concurrently when run/add/execute immediate a job. dbmsschedler use dbmsschedler master to schedule all tasks. Threads enter "dbms_schedler master lock wait" when concurrently when register a job to master. Threads enter "tenant worker lock wait" when add/remove worker from tenant worker list. majorfreeze service is the enter for launching major freeze and executing admin merge operations. Threads enter 'majorfreeze service lock wait' when concurrently executing launching majorfreezeclearmerge_error etc. majorfreeze service highly depends on 'leader'. we expect that when occuring switchrole, it can finish quickly. Due to the long time of majorfreeze usually, we hope that theads enter 'majorfreeze lock wait' when concurrently executing launching majorfreeze and switchrole thread enter 'majorfreeze switch lock wait' when concurrently executing switchtoleader and switchto_follower. Although we guess that this concurrent situation may happen rarely zone merge manager is used to manage all operations on zonemergeinfo and globalmergeinfo. To get a higher performance, we use ObZoneMergeMgrGuard to solve 'write-read' concurrent situation. When start write operation, it will get a snapshot of zone merge mgr, and all the ops will execute on the snapshot. Threads enter 'zone merge manager read lock wait' when concurrently executing re-write snapshot to zone merge mgr and read from zone merge mgr. thread enter 'zone merge manager write lock wait' when concurrently executing 'write-write' operations. For each auto-increment column, there is a cached table node and stored in the hashmap. The initialization and clearing of the table node will controlled by the lock. Thread allocate auto-increment value wait. In order to ensure the uniqueness of the value generated by the auto-increment column, the operation of allocating the auto-increment value must be atomic. Synchronous auto-increment column value when there is an insert into auto-increment column with specified value request. Global auto-increment service operation lock, the central node needs to maintain cache information and ensure atomic operations. Global auto-increment service guaranteed the only leader address in global. Thread to refresh the table location cache and update the leader address acquire the lock. Dag is used to handle various tasks, such as Compaction and Migration. The operations like adding task to Dag should be mutually exclusive. DagNet contains many Dag, which are executed in a specific order. The operations like adding child dag to DagNet should be mutually exclusive. SysTaskStatMgr records current sys task info, and the operations like adding task, updating task and deleting task should be mutually exclusive. InfoMgr is used to record infos such as warning infos of Dag that running failed, and the read/write operations on InfoMgr should be mutually exclusive. When error occurs in minor/major compaction, we need to dump all sstables for anaylazing, and the operations in merge dumper should be mutually exclusive. Updating context infos to tablet merge info in parallel compaction task should be mutually exclusive. The wash thread on kvcache store and updating cache priority should be mutually exclusive. The read and write operation on kvcache inst_map should be mutually exclusive. The read and write operation on kvcache listmap in instmap should be mutually exclusive. The read and write operation on kvcache hazard version threadstores should be mutually

The read and write operation on kvcache configs in global kvcache instance should be mutual exclusive. The read and write operation on configs in global io manager instance should be mutually exclusive. The read and write operation on tenant map in global io manager instance should be mutually exclusive. The read and write operation on diagnose info in global io detector instance should be mutually exclusive. table api query session lock. avoid concurrent access to same session. The read and write operation on last submit log info in sliding window of palf should be mutually exclusive. The read and write operation on committed info in sliding window of palf should be mutually exclusive. The read and write operation on last slide log info in sliding window of palf should be mutually exclusive. The read and write operation on fetch log info in sliding window of palf should be mutually exclusive. The read and write operation on sw match lsn map in sliding window of palf should be mutually exclusive. The read and write operation on sw location cache cb in sliding window of palf should be mutually exclusive. The read and write operation on config data in config mgr of palf should be mutually exclusive. The read and write operation on parent info in config mgr of palf should be mutually exclusive. The read and write operation on child info in config mgr of palf should be mutually exclusive. The read and write operation on state of palf handle impl should be mutually exclusive. This lock protects basic state of a palf handle impl instance. The read and write operation on log storage meta info in multiple threads should be mutually exclusive. The read and write operation on palf env meta info in multiple threads should be mutually exclusive. Registering sub role change handler to role change handler should be mutually exclusive. The read and write operation on progress indices in progress controller of cdc connector should be mutually exclusive. The read and write operation on meteinfo in meta manager of cdc connector should be mutually exclusive. The read and write operation on transaction context in cdc connector should be mutually exclusive. The read and write operation on server black list in cdc connector should be mutually exclusive. The read and write operation on server list in sql server provider of cdc connector should be mutually exclusive. The read and write operation on timezone info in cdc connector should be mutually exclusive. The read and write operation on state and rpc request in FetchLogARpc in cdc connector should be mutually exclusive. The read and write operation on fetchstream container in cdc connector should be mutually exclusive. The read and write operation on external server black list in logroute service should be mutually exclusive. The read and write operation on configs in replay status should be mutually exclusive. The read and write operation on configs in replay status basic task should be mutually exclusive. Updating or getting max apply scn in apply status should be mutually exclusive. The read and write operation on configs in gc handler should be mutually exclusive. The read and write operation on source(RemoteLogParent) in ClientLSCtx should be mutually exclusive. The read and write operation on hbresponses should be mutually exclusive. The read and write operation on allserversinfointable_ should be mutually exclusive. The read and write operation on ObLogExternalStorageIOTaskCtx should be mutually exclusive. The read and write operation on ObLogExternalStorageIOHandler should be mutually exclusive. The read and write operation on ObLogExternalStorageIOHandler should be mutually exclusive.