Coldfusion: Lese- und Schreibzugriffe auf gemeinsame Variablen sperren

Mit CFMX können auch Daten im Speicher des Servers abgelegt werden. So können applikationsweite Daten leicht gecacht oder benutzerspezifische Daten wie zum Beispiel ein Einkaufswagen gemanagt werden. Multithreading und persistente Daten sind nützliche und machtvolle Funktionen. Doch sind damit auch Implikationen verbunden, mit denen Entwickler sorgfältig umgehen müssen. In diesem Artikel geht es darum zu erklären, warum Lese- und Schreibzugriffe auf gemeinsame Variablen in Coldfusion MX ordentlich gelocked werden müssen. Außerdem werden einige Implikationen des Speicherns von Instanzen von Coldfusion Components (CFCs) in Shared Scopes aufgezeigt.

Warum sperren?

Die meisten Coldfusion-Entwickler achten in gewissem Maße auf das Locking von Threads. Ein bewährtes und wahres Beispiel ist etwas in dieser Art: Wenn man zum Beispiel Code hat, der eine Applikationsvariabel enthält. Eine Variable in einem Application-Scope ist eine speicherresidente Variabel, die allen Benutzern und Threads einer bestimmten CF-Applikation gemeinsam ist:

Das sieht ganz einfach aus, doch was ist, wenn zwei Benutzer dieselbe Seite zur selben Zeit aufrufen? Dann kann Datenkorruption entstehen:

• Benutzer A startet die Seite
• Benutzer B startet die Seite
• Benutzer A’s Thread kommt zum Zähler und liest application.counter, der auf 25 steht.
• Benutzer B’s Thread kommt zum Zähler und liest application.counter, der auf 25 steht.
• Benutzer A’s Thread erhöht den gelesenen Zählerstand (25) auf 26.
• Benutzer B’s Thread erhöht den gelesenen Zählerstand (25) auf 26.

Klar ist, dass der Zähler am Ende auf 26 steht (ein Wert, der nicht korrekt ist). Um diese Situation, eine so genannte Race Condition (weil zwei Threads um die Wette laufen, um als Erster die Daten zu bekommen), zu vermeiden, muss man einen Single-Thread Access für dieses Code-Stückchen setzen, indem man das <cflock>-Tag verwendet:

Dadurch kann immer nur ein Thread gleichzeitig diesen Code ausführen. Wenn also der Thread von Benutzer A diesen Code zuerst erreicht, wird er einen Exclusive-Lock auf diesen Code setzen, bis er mit ihm fertig ist. Wenn Benutzer B’s Thread hier ankommt, wird er auf den Lock treffen und warten, bis er aufgehoben wird, und dann seinen eigenen Lock setzen, um seine eigene Inkrementierung der Applikationsvariabel durchzuführen. Als Ergebnis wird Benutzer B’s Zähler korrekt auf 27 gestellt.

Es gibt zwei mögliche Werte für das „type“-Attribut des Tags: „readonly“ und „exclusive“. Ein Read-only-Lock erlaubt so vielen Threads wie nötig, den gesperrten Code zu lesen, solange kein Exclusive-Lock auf diesem Code sitzt. Umgekehrt übernimmt ein Exclusive-Lock den vollen Besitz eines Code-Stücks und wird keinen anderen Read-only- oder Exclusive-Lock für denselben Code zulassen, bis der Lock aufgehoben ist. Für gewöhnlich werden Read-only-Locks verwendet, wenn Daten aus einem Shared Scope nur gelesen werden. Exclusive-Locks werden benötigt, wenn Daten in einem gemeinsamen Bereich modifiziert werden, wie im oben angeführten Beispiel mit dem Zähler.