locking mainteanence queries + dep updates (#216)

* locking mainteanence queries + dep updates

* versioning stuff [skip ci]

* bypass loop delay in subscriptions if interval is met

.gitignore

@@ -2,3 +2,4 @@ node_modules
 coverage/
 *.tgz
 .nyc_output/
+.vscode

CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changes
 
+## 5.1.0
+
+- Added transactional locking to maintenance queries as a safeguard from deadlocks under load.
+- Removed maintenance events, `archived`, `deleted`, and `expired`.
+
 ## 5.0.8
 
 - Retention policy applied to abandoned jobs in retry state.

docs/usage.md

@@ -10,8 +10,6 @@
   - [Job table](#job-table)
 - [Events](#events)
   - [`error`](#error)
-  - [`archived`](#archived)
-  - [`expired`](#expired)
   - [`monitor-states`](#monitor-states)
 - [Static functions](#static-functions)
   - [`string getConstructionPlans(schema)`](#string-getconstructionplansschema)
@@ -149,15 +147,6 @@ boss.on('error', error => logger.error(error));
 
 > **Note: Since error events are only raised during internal housekeeping activities, they are not raised for direct API calls, where promise `catch()` handlers should be used.**
 
-
-## `archived`
-
-`archived` is raised each time 1 or more jobs are archived.  The payload is an integer representing the number of jobs archived.
-
-## `expired`
-
-`expired` is raised each time 1 or more jobs are expired.  The payload is an integer representing the number of jobs expired.
-
 ## `monitor-states`
 
 The `monitor-states` event is conditionally raised based on the `monitorStateInterval` configuration setting and only emitted from `start()`. If passed during instance creation, it will provide a count of jobs in each state per interval.  This could be useful for logging or even determining if the job system is handling its load.