Run cleanup of expired DB file locks to background job

* fixes #22819

The old way fired a DELETE statement on each destruction of the
DBLockingProvider. Which could cause a lot of queries. It's enough
to run this every 5 minutes in a background job, which in the end
could result in file locks that exists 5 minutes longer - in the
worst case and for not properly released locks.

This makes the DB based locking a lot more performant and could
result in a similar performance to the Redis based locking provider.

1 files changed, 11 insertions, 15 deletions

diff --git a/lib/private/lock/dblockingprovider.php b/lib/private/lock/dblockingprovider.php
index 647250cdb6f..c10cd8636ad 100644
--- a/lib/private/lock/dblockingprovider.php
+++ b/lib/private/lock/dblockingprovider.php
@@ -235,10 +235,17 @@ class DBLockingProvider extends AbstractLockingProvider {
 	 */
 	public function cleanExpiredLocks() {
 		$expire = $this->timeFactory->getTime();
-		$this->connection->executeUpdate(
-			'DELETE FROM `*PREFIX*file_locks` WHERE `ttl` < ?',
-			[$expire]
-		);
+		try {
+			$this->connection->executeUpdate(
+				'DELETE FROM `*PREFIX*file_locks` WHERE `ttl` < ?',
+				[$expire]
+			);
+		} catch (\Exception $e) {
+			// If the table is missing, the clean up was successful
+			if ($this->connection->tableExists('file_locks')) {
+				throw $e;
+			}
+		}
 	}
 
 	/**
@@ -257,15 +264,4 @@ class DBLockingProvider extends AbstractLockingProvider {
 			}
 		}
 	}
-
-	public function __destruct() {
-		try {
-			$this->cleanExpiredLocks();
-		} catch (\Exception $e) {
-			// If the table is missing, the clean up was successful
-			if ($this->connection->tableExists('file_locks')) {
-				throw $e;
-			}
-		}
-	}
 }