Symfony 8.2 vereinfacht das Sperren von Controllern mit dem Attribut #[Lock]

Symfony 8.2 fügt ein PHP-Attribut hinzu, #[Lock], das eine Anwendungssperre direkt auf eine Controller-Methode legt. Die am 16. Oktober von Javier Eguiluz im offiziellen Blog des Frameworks veröffentlichte Ankündigung beendet eine bekannte Last für Backend-Teams: Bisher musste man, um einen Controller gegen gleichzeitige Ausführung abzusichern, eine Lock-Factory injizieren, einen Schlüssel aufbauen, die Sperre erwerben, den Fall behandeln, dass sie bereits gehalten wird, und sie anschließend freigeben. Ein einziges Attribut ersetzt nun diese gesamte Mechanik.

#Das Problem, das das Attribut löst

Manche Aktionen dürfen niemals parallel laufen: der Import eines Produktkatalogs, die Abbuchung einer Bestellung, der Verkauf der letzten Plätze einer Konferenz oder einfach ein Doppelklick eines Nutzers auf eine Bestätigungsschaltfläche. Ohne Sperre können zwei gleichzeitige Anfragen eine Zahlung duplizieren oder einen laufenden Import beschädigen. Die Lock-Komponente existierte dafür bereits, aber ihre Low-Level-API bremste die Einführung in den am stärksten exponierten Controllern.

#Die Syntax von #[Lock]

Das Attribut wird auf eine Controller-Methode gesetzt und akzeptiert mehrere Parameter, um sein Verhalten je nach Anwendungsfall anzupassen.

Standardmäßig erhält eine Anfrage, die auf eine bereits gehaltene Sperre trifft, eine Antwort 409 Conflict. Ein als nullable deklariertes Argument vom Typ LockInterface oder SharedLockInterface ermöglicht es, die vom Attribut erworbene Sperre abzurufen und zu steuern, etwa um sie früher als am Ende der Anfrage freizugeben.

#Ein konkretes Beispiel

Der offizielle Beitrag veranschaulicht mehrere Fälle: einen exklusiven Import, einen Download, der gleichzeitige Lesezugriffe zulässt, einen Ticketverkauf, der wartet statt abzulehnen, und eine über einen Ausdruck gebildete Sperre pro Nutzer.

use Symfony\Component\ExpressionLanguage\Expression;
use Symfony\Component\HttpKernel\Attribute\Lock;
use Symfony\Component\Lock\LockInterface;
use Symfony\Component\Routing\Attribute\Route;

class CatalogController extends AbstractController
{
    #[Route('/catalog/import', methods: ['GET', 'POST'])]
    #[Lock('catalog', methods: 'POST')]
    public function import(?LockInterface $lock): Response
    {
        // ... mise à jour du catalogue
        $lock?->release(); // libération anticipée, avant les notifications
        // ... notifications sans verrou
        return new Response();
    }

    #[Route('/catalog/download')]
    #[Lock('catalog', read: true)]
    public function download(): Response { /* téléchargements simultanés autorisés */ }

    #[Route('/conference/{conference}/tickets', methods: 'POST')]
    #[Lock('ticket-sale-{conference}', blocking: true, ttl: 10)]
    public function buyTicket(Conference $conference): Response { /* attend plutôt que de rejeter */ }
}

Die letzte Methode im offiziellen Beitrag kombiniert einen ExpressionLanguage-Ausdruck mit einer benannten Factory, um pro angemeldetem Nutzer statt pro globaler Ressource zu sperren – so blockiert ein von einem Konto gestarteter Bericht nicht den eines anderen.

Die Sperre wird erworben, bevor die Methodenargumente aufgelöst werden und bevor #[IsGranted] ausgewertet wird: Ein nicht berechtigter Nutzer kann einen 409 erhalten, noch bevor er mit einem 403 abgewiesen wird.

#Einschränkungen, die man vor der Einführung kennen sollte

Drei Verhaltensweisen verdienen vor dem Produktionseinsatz eine genaue Lektüre. Erstens die Reihenfolge der Attributauswertung: #[Lock] wird vor #[IsGranted] und vor #[RateLimit] ausgeführt, was dazu führen kann, dass eine Anfrage wartet oder abgelehnt wird, obwohl sie aus einem Autorisierungsgrund hätte verweigert werden müssen. Zweitens hat der Modus blocking: true kein eigenes Timeout: Eine Anfrage kann so lange blockiert bleiben, wie die Sperre anderswo gehalten wird. Schließlich kann eine interne Teilanfrage die Sperre der Hauptanfrage wiederverwenden, weshalb das Argument LockInterface grundsätzlich als nullable deklariert werden sollte.

Diese Vereinfachung fügt sich in einen breiteren Trend bei Backend-Frameworks ein: weniger Boilerplate um bereits bestehende Primitiven, statt neue hinzuzufügen. Node.js folgte einer vergleichbaren Logik, indem es die Temporal-API standardmäßig in Version 26 auslieferte, während Symfony die Komplexität einer bereits ausgereiften Komponente hinter einem deklarativen Attribut verbirgt.

#Was man sich merken sollte

Das Attribut #[Lock] ersetzt die Lock-Komponente nicht: Es stellt deren nützlichsten Teil in deklarativer Form direkt am Controller bereit. Für Katalogimporte, Zahlungen und Verkäufe mit begrenztem Bestand ist die Einführung nahezu kostenlos, sobald die Komponente installiert ist. Teams, die bereits #[IsGranted] und #[RateLimit] kombinieren, müssen hingegen die Ausführungsreihenfolge der drei Attribute prüfen, bevor sie sie auf derselben Methode stapeln.

Zum Weiterlesen: der ausführliche offizielle Beitrag auf symfony.com/blog.