Mailinglisten-Archive |
Helmut Wirth wrote: > Meiner Meinung nach besitzt die Sitzungsverwaltung von ASP > für den praktischen Gebrauch v.a. noch folgenden Vorteil > gegenüber der bereits sehr leistungsfähigen PHP3 Basisbiblio- > thek, nämlich das Applikationsobjekt: Ja. Das ist jedoch trivial zu implementieren; vergleiche dazu die Implementierung von User-Variablen in release-5. Ohne Locking wuerde ich es jedoch nicht einmal versuchen und mit Locking ist es nicht portable ueber verschiedene Datenbanken (es geht dann nur mit MySQL). Wenn mir jemand zeigt, wie ich die entsprechenden Locking-Direktiven fuer Postgres hinbekomme, mache ich Applikationsvariablen standardmaessig rein. > implementieren lassen, doch für eine effiziente Implemen- > tierung von application.lock() / application.unlock() wird > man wohl mindestens eine Ebene tiefer eingreifen müssen. Noe. Fuer MySQL ist der Code bereits da und ein "appl"-Feature ist wie gesagt trivial zu realisieren. Problem ist die Portabilitaet mit dem Locking. Jede Anwendung wuerde eine Zeile in der active_sessions Tabelle bekommen, die so aussieht: sid name val changed Anwendungsname Poe_Appl Die variablenzuweisungen hier 19980911010203 Jedesmal, wenn ein page_open() mit einem "appl" => "Poe_Appl" Feature gemacht wird, muss diese Zeile gelockt werden. Bei einem page_close() wird das Lock wieder released. In MySQL wird dazu ein "select get_lock('anwendungsname') bzw. ein "select release_lock('anwendungsname')" gemacht; leider geht das nur mit busy waiting - ein weiterer Minuspunkt. Wie kriege ich das in Postgres sauber hin? Dann haben wir Anwendungsvariablen... Kristian -- SH Online Dienst GmbH, Kristian Koehntopp, Siemenswall, 24107 Kiel, +49 431 386 436 00 Using PHP3? See our web development library at http://phplib.shonline.de/ (GPL)
php::bar PHP Wiki - Listenarchive