Locking In CFML

Locking in CFML - Warum - Wie - Wobei - Wann } soll gelockt werden? Locking verstehen

Locking in CFML Agenda Das Problem Kritische Ressourcen Shared Scope Variablen Geschachtelte Locks Locks um Pointer Name Locks Links * Client Variablen * * Folie nicht in Original-Präsentation enthalten Zugriffe beschränken * Lock Administration Fragen und Antworten *

Locking in CFML Symptome für ein Locking-Problem - unerklärliche Verluste von Session- oder Application-Variablen - Serverabstürze - speichergierige CF-Server - langsame Anwendungen Obwohl diese Symptome nicht bedeuten, dass ein Locking Problem vorhanden sein MUSS, ist falsches (oder gänzlich fehlendes) Locking eine der wahrscheinlichsten Ursachen.

Locking in CFML Multithreading Die Fähigkeit eines Programms, mehrere Aktivitäten parallel auszuführen Beispiel: -Programm Gleichzeitig Nachrichten lesen und neue Mails vom Server downloaden

Locking in CFML Multithreading Vorteile - Performance/Zeitersparnis - (System-) Sicherheit Nachteile - Programme werden aufwendiger - nicht einfach zu implementieren

Locking in CFML Multithreading in ColdFusion ColdFusion kann mehrere Requests gleichzeitig bearbeiten Jeder Request wird einem Thread zugeordnet Überzählige Requests werden in Warte- schlange eingereiht Im Thread wird jeder Request serialisiert Anzahl der Worker Threads kann im CF- Administrator eingestellt werden

Locking in CFML Kritische Ressourcen Shared Scope Variablen Dateien Komponenten (COM, CORBA, Java) Alle Ressourcen, die zugriffskritisch sind oder bei zu vielen gleichzeitigen Zugriffen inperformant werden Concurrent Access

Locking in CFML Shared Scope Variablen Server-Scope Application-Scope Session-Scope Variablen können von jedem User JEDER Anwendung genutzt werden Variablen können von jedem User EINER Anwendung genutzt werden Variablen können von EINEM User innerhalb EINER Anwendung genutzt werden Frames, Mehrfache Submits, Reload/Redirection

Locking in CFML Identifikation Typ Fehlerbehandlung NAME oder SCOPE TYPE=Exclusive vs. TYPE=ReadOnly TIMEOUT und THROWONTIMEOUT

Locking in CFML und Shared Scope Variablen JEDEN Zugriff locken den gesamten Scope locken den richtigen Typ einsetzen nur das locken, was gelockt werden muss Siehe Pointer und Strukturen, sowie Fragen und Antworten!

Locking in CFML Beispiel: Query-Ergebnis in Application- Variable speichern Falsch: SELECT * FROM tblKunden Besser: SELECT * FROM tblKunden

Locking in CFML Client Variablen und Locking Client Variablen werden NICHT im RAM gespeichert, Sondern in DB, Registry oder Cookies Das Betriebssystem oder die DB kümmern sich um Zugriffsprobleme In ColdFusion brauchen wir Client Variablen NICHT zu locken

Locking in CFML Geschachtelte Locks Gefahr von Deadlocks Code... Template 1: Code... Template 2: Code... Ansonsten nicht möglich!

Locking in CFML Geschachtelte Locks vermeiden Gleiches Ergebnis ohne geschachtelte Locks:

Locking in CFML Geschachtelte Locks Falls möglich, geschachtelte Locks vermeiden (Performance-Nachteile, Deadlock-Gefahr) 1. Session-Scope Falls das Schachteln von Locks unvermeidbar wird, dann immer in der Reihenfolge 2. Application-Scope 3. Server-Scope Local out - Ansatz

Locking in CFML Locking von Pointern Pointer: Verweis auf eine Struktur Änderung am Pointer ändert auch Original-Struktur Shared Scope Variablen sind auch Strukturen greift nicht nur auf myVar zu, sondern auf die gesamte Struktur application, deshalb den ganzen Scope locken! Immer!!

Locking in CFML Name Locks Lock wird durch Name identifiziert und sperrt den Ressourcen-Zugriff für alle Locks mit gleichem Namen Verwendung bei allen kritischen Ressourcen außer Shared Scope Variablen, z.B. Verity COM-Objekte Sinnvoll: Benennung nach einem Schema

Locking in CFML Anzahl gleichzeitiger Zugriffe beschränken Einige Ressourcen werden sehr inperformant, wenn zu viele gleichzeitige Zugriffe vorkommen oder erlauben nur eine bestimmte Anzahl gleichzeitiger Verbindungen von einem Client (z.B. manche FTP-Server). Mit Name Locks kann man dafür sorgen, dass nicht mehr gleichzeitige Zugriffe als vorgesehen vorkommen. Dazu muss man eine festgelegte Anzahl möglicher Lock-Namen für die Ressource haben, z.B. mit Hilfe der Random-Funktionen: Da drei verschiedene Namen möglich sind, können zum FTP-Server MyServer maximal drei gleichzeitige Verbindungen aufgebaut werden.

Locking in CFML Lock-Administration Single Threaded Sessions Alle Threads mit der gleichen sessionID werden serialisiert Keine Gefahr von Concurrent Access bei Sessions u.U. Performance-Nachteile (z.B. bei Frames) Erhöhte Gefahr von Template-Timeouts

Locking in CFML Lock-Administration Variable Scope Lock Settings No automatic checking or locking Full checking Automatic read locking

Locking in CFML Lock-Administration Variable Scope Lock Settings No automatic checking or locking Locking liegt in der Verantwortung des Entwicklers Performant aber gefährlich Bei Produktiv-Servern mit GETESTETEN Anwendungen

Locking in CFML Lock-Administration Variable Scope Lock Settings Full checking Jeder nicht gelockte Zugriff erzeugt Fehler Sicher, hat aber leichte Performance-Nachteile Auf Entwicklungsservern Auf shared Servern Name Locks erzeugen ebenfalls Fehler Achtung Bug! Ein fehlender Lock um IsDefined() bei Shared Scope Variablen erzeugt auch bei Full Checking keinen Fehler! Aber auch IsDefined(shared_scope_var) MUSS gelockt werden! Achtung Bug! Ein fehlender Lock um IsDefined() bei Shared Scope Variablen erzeugt auch bei Full Checking keinen Fehler! Aber auch IsDefined(shared_scope_var) MUSS gelockt werden!

Locking in CFML Lock-Administration Variable Scope Lock Settings Automatic read locking Jeder Lesezugriff erhält seinen eigenen Lock Relativ sicher, aber definitve Performance-Nachteile Wenn alte Anwendungen nachträglich mit Locks versehen werden müssen Schreibende Zugriffe müssen manuell gelockt werden

Locking in CFML Zusammenfassung 1. Jeden Zugriff locken 2. Wenn möglich, mehrere Zugriffe in einen Lock packen, aber 3. Nur das locken, was auch gelockt werden muss 4. Für Shared Scope Variablen immer das SCOPE-Attribut verwenden 5. Den richtigen Lock-Typ verwenden 6. Bei shared Servern den Server-Scope vermeiden

Locking in CFML Zusammenfassung 8. THROWONERROR=Yes ist nützlich, erfordert aber die Verwendung von CFTRY/CFCATCH 9. Pointer zwischen verschiedenen Scopes vermeiden. (Besser StructCopy() oder Duplicate() verwenden) 10. Wenn Pointer unvermeidbar sind: Beide Scopes locken 11. Für Produktiv-Server: No automatic checking or locking aktivieren (bei GETESTETEN Anwendungen) 12. Für Entwicklungs-Server: Full checking aktivieren 7. Geschachtelte Locks vermeiden, wenn geschachtelt werden muss: Local out

Locking in CFML Fragen und Antworten hängt doch automatisch das session.URLToken an die URL an, muss ich das nicht auch locken? Es wird nicht das SESSION.URLToken angehängt, sondern das CLIENT.URLToken. Das ist in der CF-Dokumentation zu CFLOCATION leider nur dem kleinen Vermerk clientManagement must be enabled zu entnehmen. Da es sich also um eine Client Variable handelt, muss nicht gelockt werden. Warum muss bei Shared Scope Variablen der ganze Scope gelockt werden, es sollte doch reichen, die einzelne Variable zu locken, oder? Wenn wir auf eine Shared Scope Variable zugreifen, dann greifen wir immer auf eine Struktur zu. Es nutzt nichts, ein einzelnes Element zu locken, wenn die übergeordnete Einheit ungeschützt ist und durch concurrent access kompromitiert werden kann. Deswegen IMMER den ganzen Scope locken. Beim Server-Scope können zwar aus Sicherheitsgründen die Struktur-Funktionen von CF nicht verwendet werden (auch funktioniert nicht), es aber dennoch eine Struktur und muss dementsprechend geschützt werden. Wenn wir auf eine Shared Scope Variable zugreifen, dann greifen wir immer auf eine Struktur zu. Es nutzt nichts, ein einzelnes Element zu locken, wenn die übergeordnete Einheit ungeschützt ist und durch concurrent access kompromitiert werden kann. Deswegen IMMER den ganzen Scope locken. Beim Server-Scope können zwar aus Sicherheitsgründen die Struktur-Funktionen von CF nicht verwendet werden (auch funktioniert nicht), es aber dennoch eine Struktur und muss dementsprechend geschützt werden.

Locking in CFML Fragen und Antworten Warum muss denn partout JEDER Zugriff gelockt werden? Ein einzelner ungelockter Zugriff beeinflusst doch die anderen gelockten Zugriffe nicht.... FALSCH! Ganz wichtig ist das richtige Verständnis von Locks. Ein Lock schützt nur vor Zugriffen aus anderen gleichartigen Locks heraus. Ein Lock um eine Application-Variable schützt diese Variable nicht vor ungelockten Zugriffen, sondern nur vor Zugriffen aus Locks mit dem gleichen Scope-Attribut. Deswegen ist Name-Locking auch so kritisch. Zwei Locks mit unterschiedlichem Namen können auf die gleiche geschützte Ressource zugreifen. Um da nicht die Übersicht zu verlieren sollte man bei Shared Scope Variablen immer das SCOPE-Attribut benutzen und für Name Locks eine Naming Convention einhalten. FALSCH! Ganz wichtig ist das richtige Verständnis von Locks. Ein Lock schützt nur vor Zugriffen aus anderen gleichartigen Locks heraus. Ein Lock um eine Application-Variable schützt diese Variable nicht vor ungelockten Zugriffen, sondern nur vor Zugriffen aus Locks mit dem gleichen Scope-Attribut. Deswegen ist Name-Locking auch so kritisch. Zwei Locks mit unterschiedlichem Namen können auf die gleiche geschützte Ressource zugreifen. Um da nicht die Übersicht zu verlieren sollte man bei Shared Scope Variablen immer das SCOPE-Attribut benutzen und für Name Locks eine Naming Convention einhalten. Welche Naming Convention soll ich für Name Locks verwenden? Ganz egal, es sollte nur eine Systematik dahinterstecken. So könnte der Lock-Name grundsätzlich aus Lock + geschützte Ressource bestehen, also z.B. Lock_files oder Lock_ftp. Ganz egal, es sollte nur eine Systematik dahinterstecken. So könnte der Lock-Name grundsätzlich aus Lock + geschützte Ressource bestehen, also z.B. Lock_files oder Lock_ftp.

Locking in CFML Links Best practices: A comprehensive guide: /Locking/Index.cfm BF on CF: Lock it or loose it!

Locking in CFML Weitere Fragen? Christoph Schmitz Jeweils aktuelle Version der Präsentation zu finden unter