Ein paar Tabellen

Mit dem Wissen über Notifikationen können wir nun den Chat-Server planen. Wegen der Länge der Listings sind sie hier nur auszugsweise wiedergegeben. Das vollständige Paket kann unter [3] heruntergeladen werden.

Um das Beispiel einfach zu halten, verzichtet es auf jegliche Benutzerverwaltung. Jeder Teilnehmer kann jeden Chat-Raum betreten und unter einer beliebigen Identität teilnehmen. Auch können mehrere Benutzer gleichzeitig unter demselben Namen auftreten. Chat-Räume entstehen nach Bedarf.

In der Datenbank sind zwei Tabellen vorgesehen, eine für die Chat-Räume und eine für die Nachrichten ( Listing 4 ).

Der für das Thema interessante Teil ist jedoch der in Listing  5 dargestellte Trigger. In den Zeilen 11 und 12 wird der Trigger erzeugt. Er feuert bei jedem »INSERT« in die »chat_msgs« -Tabelle und führt dabei die Funktion »chat_tg_fn« aus. Diese ermittelt den Namen des Chat-Raums und bildet daraus die Notifikation

r_RAUMNAME

Zum Test lässt sich das Programm in Listing  1 so modifizieren, dass es auf »r_foo« und »r_bar« reagiert. Dann erzeugt man mit »psql« einen Chat-Raum »foo« und fügt als Nächstes eine Mitteilung ein. Das Skript meldet dann eine »r_foo« -Notifikation.

Gerüstbau

Datenbankseitig war es das schon. Listing  6 enthält das Gerüst des Perl-Moduls für den Chat-Server. Der Einstieg ist die Handler-Funktion am Ende. Um es einfach zu halten, kommuniziert die HTML-Seite mit dem Modul nur über AJAX und benutzt dabei die HTTP-Methode »POST« . Parameter werden in JSON kodiert übertragen. Die Antwort wird auch in JSON erwartet.

Daher liest Zeile  75 den Request-Body ein, den Zeile  76 dekodiert. Das Resultat landet in der globalen Variable »$data« . War das erfolgreich, wird die Verbindung zur Datenbank aufgebaut und auch in einer globalen Variable gespeichert. Alle drei globalen Variablen, die Anfrage »$r« , »$data« und die Datenbankverbindung »$db« , werden lokalisiert. Das heißt, sie werden automatisch zu »undef« zurückgesetzt, sobald das Programm die Handler-Funktion verlässt, auch wenn das mittels »die« in einer Unterfunktion passiert.

Jede Anfrage muss den Parameter »action« enthalten. Er gibt an, was eigentlich gemacht werden soll. Der Hash »%actions« in Zeile  56 verzweigt dann entsprechend des Parameters. Im Moment kennt das Modul nur die Aktion »test« .

Diese Architektur widerspricht dem REST-Paradigma. In der Praxis gibt es sicher einige Aktionen, die idempotent sind und daher mittels GET und über eine separate URL ansprechbar sein sollten. Aber das Ganze ist nur ein Beispiel.

Der für das Thema interessante Teil spielt sich in der Query-Funktion ab. Hier wird wie in [1] »AnyEvent« benutzt. Der Event-Loop ist also der »recv« -Aufruf auf der Condition-Variable in Zeile  50. Hier wird gewartet, bis eine der folgenden Bedingungen erfüllt ist:

• die Anfrage ist beendet (Zeile  35),
• die Anfrage hat ihr Zeitlimit überschritten (Zeile  34),
• ein SIGINT oder SIGTERM ist eingetroffen (Zeile  45).

Nun unterscheidet sich das Umfeld für einen Mod-Perl-Handler etwas von einem Mod-CGI-Skript. Das SIGTERM hat hier eine komplett andere Bedeutung. Es tritt nicht auf, wenn der Webserver meint, die Anfrage dauere zu lange, sondern nur, wenn er sich beenden will. Daher bricht der Signal-Handler »$cancel_and_terminate« nicht nur die SQL-Anfrage ab, sondern setzt mit »child_terminate« auch ein Flag, das anzeigt, dass der Prozess enden soll, sobald die Anfrage abgearbeitet ist.

Auch treten in Mod-Perl-Handlern keine Timeouts auf. Wie in [1] ausgeführt, bezieht sich der Timeout des Webservers auf die Überwachung von I/O-Strömen. Während des Query-Aufrufs gibt es aber keinen Datenaustausch mit dem Browser – das ist der einzige Kanal, den der HTTPD kennt. Von der Datenbankverbindung hat er keine Ahnung.