Context of the owner of metadata locks. More...
Context.
Create copy of all granted tickets of particular duration from given context to current context.
Used by XA for preserving locks during client disconnect..
Remove the wait-for edge from the graph after we're done waiting.
Try to find a deadlock.
This function produces no errors.
Find the first context which owns the lock and inspect it by calling MDL_context_visitor::visit_context() method.
Check whether the context already holds a compatible lock ticket on an object.
Start searching from list of locks for the same duration as lock being requested. If not look at lists for other durations.
Allocate pins which are necessary to work with MDL_map container if they are not allocated already.
Get pseudo random value in [0 .
. 2^31-1] range.
Within MDL subsystem this one is only used for DEBUG_SYNC.
Do not use it to peek/poke into other parts of THD from MDL.
Does this savepoint have this lock?
Does this context have an lock of the given namespace?
Do we hold any locks which are possibly being waited for by another MDL_context?
"Materialize" requests for locks which were satisfied using "fast path" by properly including them into corresponding MDL_lock::m_granted bitmaps/lists and removing it from packed counter in MDL_lock::m_fast_path_state.
Auxiliary function which allows to check if we have some kind of lock on a object.
Returns true if we have a lock of an equal to given or stronger type.
Auxiliary function which allows to check if we have some kind of lock on a object.
Returns TRUE if we have a lock of an equal to given or stronger type.
Release all explicit locks in the context which correspond to the same name/object as this lock request.
Release lock.
Release lock with explicit duration.
Release all explicit locks in the context for which the release() method of the provided visitor evalates to true.
Release all locks associated with the context.
If the sentinel is not NULL, do not release locks stored in the list after and including the sentinel.
Statement and transactional locks are added to the beginning of the corresponding lists, i.e. stored in reverse temporal order. This allows to employ this function to:.
Auxiliary method for acquiring lock without waiting..
Indicates that we need to use DEADLOCK_WEIGHT_DML deadlock weight for this context and ignore the deadlock weight provided by the MDL_wait_for_subgraph object which we are waiting for.
Read-write lock protecting m_waiting_for member.
true - if for this context we will break protocol and try to acquire table-level locks while having only S lock on some table.
To avoid deadlocks which might occur during concurrent upgrade of SNRW lock on such object to X lock we have to abort waits for table-level locks for such connections. false - Otherwise.
Thread's pins (a.k.a.
hazard pointers) to be used by lock-free implementation of MDL_map::m_locks container. NULL if pins are not yet allocated from container's pinbox.
State for pseudo random numbers generator (PRNG) which output is used to perform random dives into MDL_lock objects hash when searching for unused objects to free.
Lists of all MDL tickets acquired by this connection.
The entire set of locks acquired by a connection can be separated in three subsets according to their duration: locks released at the end of statement, at the end of transaction and locks are released explicitly.
Statement and transactional locks are locks with automatic scope. They are accumulated in the course of a transaction, and released either at the end of uppermost statement (for statement locks) or on COMMIT, ROLLBACK or ROLLBACK TO SAVEPOINT (for transactional locks). They must not be (and never are) released manually, i.e. with release_lock() call.
Tickets with explicit duration are taken for locks that span multiple transactions or savepoints. These are: HANDLER SQL locks (HANDLER SQL is transaction-agnostic), LOCK TABLES locks (you can COMMIT/etc under LOCK TABLES, and the locked tables stay locked), user level locks (GET_LOCK()/RELEASE_LOCK() functions) and locks implementing "global read lock".
Statement/transactional locks are always prepended to the beginning of the appropriate list. In other words, they are stored in reverse temporal order. Thus, when we rollback to a savepoint, we start popping and releasing tickets from the front until we reach the last ticket acquired after the savepoint.
Locks with explicit duration are not stored in any particular order, and among each other can be split into four sets:
If our request for a lock is scheduled, or aborted by the deadlock detector, the result is recorded in this class.
Tell the deadlock detector what metadata lock or table definition cache entry this session is waiting for.
In principle, this is redundant, as information can be found by inspecting waiting queues, but we'd very much like it to be readily available to the wait-for graph iterator.