Server / Storage engine interface

Registration

To expose DATA_LOCKS to the performance schema, a storage engine needs to:

implement a sub class of PSI_engine_data_lock_inspector
register it with the performance schema on init
unregister it with the performance schema on deinit

While the storage engine is in use (between init and deinit), the performance schema keeps a reference to the data lock inspector given, and use it to inspect the storage engine data locks.

Iteration for each storage engine

When the server performs a SELECT * from performance_schema.data_locks, the performance schema creates a PSI_server_data_lock_container for the duration of the table scan.

Then, the scan loops for each storage engine capable of exposing data locks (that is, engines that registered a data lock inspector).

For each engine, the inspector is called to create an iterator, dedicated for this SELECT scan.

Iteration inside a storage engine

When table_data_locks::rnd_next() is first called, the performance schema calls the storage engine iterator, which adds N rows in the data container.

Upon subsequent calls to table_data_locks::rnd_next(), data present in the container is returned. This process loops until the storage engine iterator finally reports that it reached the end of the scan.

Note that the storage engine iterator has freedom to implement:

either a full table scan, returning all rows in a single call,
or a restartable scan, returning only a few rows in each call.

The major benefit of this interface is that the engine iterator can stop and restart a scan at natural boundaries within the storage engine (say, return all the locks for one transaction per call), which simplifies a lot the storage engine implementation.