mirror/zoneminder
1
0
Fork 0
mirror of https://github.com/ZoneMinder/zoneminder.git synced 2026-05-24 22:47:06 -04:00
Code Issues Packages Projects Releases Wiki Activity

docs: expand triggers.sql lock-order block with full writer list

Browse Source 
Adds zm_event.cpp's create path (Events INSERT -> bucket INSERTs ->
Event_Summaries UPDATE; event_insert_trigger itself is commented out so
zmc does this directly), and lists zmaudit.pl alongside zmstats.pl, so
the comment enumerates every writer obligated to follow the canonical
order rather than just the trigger paths.
This commit is contained in:
Isaac Connor
2026-05-16 22:44:14 -04:00
parent 7b4617b1ad
commit e254ed41d2
1 changed files with 20 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
db/triggers.sql
View File

@@ -117,16 +117,27 @@ FOR EACH ROW
drop procedure if exists update_storage_stats//
/* ============================================================================
* Lock-acquisition order for the Events update/delete triggers (and for the
* scripts that touch the same tables). InnoDB X-locks the matched Events row
* during WHERE evaluation, before either BEFORE or AFTER trigger bodies fire,
* so the order is the same regardless of trigger timing:
* Canonical lock-acquisition order for every writer that touches Events,
* the bucket tables, and Event_Summaries. InnoDB X-locks the matched Events
* row during WHERE evaluation, before either BEFORE or AFTER trigger bodies
* fire, so the order is the same regardless of trigger timing:
*
* Events[Id] -> Events_Hour/Day/Week/Month[EventId] -> Event_Summaries[MonitorId]
* zmstats.pl prune+resync follows the matching prefix (bucket DELETEs then
* UPDATE Event_Summaries) and crucially does NOT pre-lock Event_Summaries —
* pre-locking ES would invert against the trigger body order and reintroduce
* deadlocks against filter / zma writers. The bucket update/delete triggers
* also propagate into Event_Summaries[MonitorId] in the same direction.
*
* Writers that follow this order (and must continue to):
* - event_update_trigger (AFTER UPDATE on Events)
* - event_delete_trigger (BEFORE DELETE on Events)
* - src/zm_event.cpp Event::createNotification path: INSERT Events, then
* INSERT Events_Hour/Day/Week/Month, then INSERT/UPDATE Event_Summaries
* (event_insert_trigger is commented out below; zmc does it directly)
* - The bucket update/delete triggers cascade into Event_Summaries in the
* same direction
* - zmstats.pl prune+resync (bucket DELETEs then UPDATE Event_Summaries)
* - zmaudit.pl resync (bucket SELECTs then UPDATE Event_Summaries)
*
* Crucially: do NOT pre-lock Event_Summaries before touching the bucket
* tables — that inverts the order and reintroduces the deadlock cycle
* against zma/filter/zmc writers.
* ============================================================================ */
drop trigger if exists event_update_trigger//