Coldfusion: Lese- und Schreibzugriffe auf gemeinsame Variablen sperren

Das hört sich großartig an, aber muss hier nicht irgendwo ein Lock gesetzt werden, weil der Application-Scope verwendet wird? Auf jeden Fall! Doch mit etwas Umsicht kann die Menge der nötigen Locks klein gehalten werden.

Eine einzelne newsManager-Instanz wird allen Benutzern der gesamten Applikation gemeinsam sein (wie durch den Namen, der im -Tag verwendet wurde, definiert). Daher muss sie nur einmal erzeugt werden, beim ersten Mal, wenn irgendein Benutzer die Applikation verwendet. So wird nur ein Exclusive-Name-Lock für diesen Code benötigt, und er muss beim Start der Applikation laufen:

Zu beachten ist, dass designbedingt application.newsManager nur einmal während der Lebensdauer einer Applikation erzeugt wird. Sobald er einmal erzeugt wurde, wird sich sein interner Status nicht ändern. Das hat eine wichtige Konsequenz: Es bedeutet, dass keine weiteren Lesezugriffe auf application.newsManager gesperrt werden müssen. Eine Race Condition ist nicht möglich. Und zwar deshalb, weil application.newsManager eine stateless CFC ist, die keine Instanzdaten hat, die sich ändern – tatsächlich hat sie überhaupt keine Instanzdaten (Zu beachten ist, dass bei einem Framework wie Mach-II das Framework selbst die Erzeugung von hörenden Komponenten im Application-Scope managt.).

Dadurch reduziert sich die Menge der notwendigen Locks, das bedeutet aber auch, dass man der Design-Entscheidung treu bleiben muss, der zufolge der newsManager eine stateless CFC ist. Es muss sichergestellt werden, dass kein anderer Entwickler aus Versehen application.newsManager ohne korrektes Locking neu erzeugt. Genauer gesagt heißt das, dass die application.newsManager CFC keine internen Instanzdaten enthalten soll, die modifiziert werden. Warum? Da die newsManager-CFC-Instanz im Application-Scope besteht, existieren auch alle Instanzdaten, die sie enthält, im Application-Scope.

Das bedeutet, keine Daten innerhalb der CFC dürfen in den „variables“-Scope (oder den „this“-Scope) geschrieben werden. Da die newsManager CFC keine Instanzdaten hat, kann die Notwendigkeit, Methoden-Aufrufe für diese CFC-Instanz zu sperren, schadlos vermieden werden. Das kann man sich selbst anschauen, wenn man den newsManager-Code in Listing A betrachtet.

Listing A

Beispiel eins

Zu Listing A ist anzumerken, dass in der Methode getRecentNewsItems() die Query-Variabel „qRecentNewsItems“ im „var“-Scope definiert wurde. Dies sagt CF, dass qRecentNewsItems eine Method-local-Variable ist. Sie wird nur so lange wie der Aufruf der Methode bestehen und ist kein Instanzdatum.

Man kann nicht genug betonen, wie wichtig die korrekte Verwendung des var-Scopes in CFC-Methoden ist! Wenn der var-Scope nicht für die Query-Variable verwendet worden wäre, hätte CF sie in den „variables“-Scope geschrieben. Dies wären Instanzdaten, und die CFC wäre dann potenziellen Race Conditions ausgesetzt, wenn mehrere Threads sie gleichzeitig aufrufen würden. Daher den var-Scope für alle Method-Local-Variablen verwenden, um diese heimtückische Gefahr zu vermeiden! Tut man das nicht, wird es Probleme geben, wenn die Applikation unter Last steht.