client-seitige Sessions mit Servlets

[deamon]

Hallo,

normalerweise werden Sessions als Datenstrukturen auf dem Server verwaltet. Das bringt jedoch Probleme mit sich, die insbesondere in Clustern auftreten können. Die REST-Architektur sieht deshalb als radikale Lösung vor, überhaupt keine Sessions auf dem Server zu verwalten, sondern den Sitzungszustand ausschließlich auf dem Client zu verwalten. So lautet jedenfalls die Theorie.

Aber wie könnte man denn die Sitzung auf dem Client verwalten? Mir fallen dazu mehrere Möglichkeiten ein:

* Cookies - man muss von max. 4 KB je Cookie und max. 20 Cookies je Host ausgehen
* Versteckte Formularfelder - funktionieren nur bei POST, oder man muss alle Links zu Formularen machen.
* URL-Parameter - funktionieren mit GET und POST, aber die Länge ist stark begrenzt
* Man könnte mit AJAX immer auf derselben Seite bleiben und den Zustand mit JavaScript verwalten, allerdings würde der Benutzer dann immer die gleiche URL für verschiedene Seiteninhalte sehen.

Die AJAX-Lösung hätte technisch wohl die wenigsten Beschränkungen, würde aber zu dem erwähnten Nachteil mit den URLs führen und noch dazu JavaScript erzwingen. Da eh fast jeder JavaScript aktiviert hat, wäre wohl nur die Sache mit den URLs interessant, die stört mich dafür aber gewaltig.

Alle Links zu Formularen umzubauen, um versteckte Felder zu übertragen, halte ich auch nicht gerade für elegant. Zumal wenn man nicht in schlechtester JSF-Manier alles mit POST machen wollte, auch bei der Länge begrenzt wäre. Gleiches gilt natürlich auch für URL-Parameter, auch wenn sie per POST verschickt.

Da bleiben dann ja eigentlich nur noch Cookies mit ihrer Größenbeschränkung und der Gefahr, dass der Client sie nicht akzeptiert. Wenn man von 20 Cookies à 4 KB ausgeht, hätte man immerhin 80 KB für die Session. Das ist nicht wirklich viel, aber dicke Objekte haben in der Session eh nichts zu suchen. Aber was ist mit evtl. sehr lang laufenden Sessions, in deren Verlauf vielleicht sehr viele kleine Objekte (Ints, Strings ...) zusammen kommen? Damit könnte man dann auch an diese Grenze stoßen.

Hat damit jemand praktische Erfahrungen gesammelt? Welche Lösung hat sich bewährt, welche Probleme gibt es? Oder ist die Verwaltung der Session auf dem Client doch eher Theorie und in der Praxis kommt man um eine Session auf dem Server nicht herum?

 

[JanHH]

Was sind denn genau die Probleme, die bei der normalen, serverseitigen Variante bestehen? Vielleicht gibts ja noch andere Möglichkeiten, diese in den Griff zu bekommen.

 

[deamon]

Ich überlege im Moment, wie weit man die REST-Prinzipien, wozu auch der verzicht auf Sitzungen auf dem Server gehört, in der Praxis umsetzen kann. Die Gedanke dahinter ist, dass die Replikation von Sitzungen auf Servern in einem Cluster weder Wartungsaufwand verursacht noch den Ressourcenbedarf erhöht. Und die Ausfallsicherheit wird natürlich auch erhöht, weil es ja keine Sitzung gibt, die eventuell verloren gehen könnte (wenn man von einem Server zum anderen wechseln muss).

Das sind also theoretische Überlegungen, wie man ein potenzielles Problem grundsätzlich vermeiden könnte. Allerdings scheint mir die Verwaltung von Sitzungen auf dem Client auch nicht ganz trivial zu sein, so dass die REST-Philosophie in der Praxis vielleicht gar nicht immer geeignet ist. Ob es vielleicht doch praktikable Wege gibt, den Zustand auf dem Client zu speichern, will ich mit dieser Diskussion herausfinden.

 

[JanHH]

Naja, Du hast ja selber sämtliche Möglichkeiten samt ihren Nachteilen aufgezählt. Viel gibts da dann ja eigentlich nicht mehr zu diskutieren, und andere Möglichkeiten gibt es auch nicht. Von den aufgezählten kommt mir die Variante mit hidden-Parameter und POST am besten vor (kennt man ja von JSF auch schon, und funktioniert da ja auch ganz gut). Optimal ist es allerdings natürlich auch noch nicht, die Nachteile sind ja bekannt.

Frage mich allerdings, ob es nicht eher eine theoretische Sache ist, und die Probleme in einem Rechnerverbund in der Praxis überhaupt gravierend sind. Ist es nicht gerade einer der Kernpunkte der EJB-Technologie, problemlos verteilte Anwendungen zu ermöglichen, und auch "Hochverfügbarkeit" bzw. Ausfallsicherheit einzelner Server zu realisieren?

 

[maki]

Frage mich allerdings, ob es nicht eher eine theoretische Sache ist, und die Probleme in einem Rechnerverbund in der Praxis überhaupt gravierend sind. Ist es nicht gerade einer der Kernpunkte der EJB-Technologie, problemlos verteilte Anwendungen zu ermöglichen, und auch "Hochverfügbarkeit" bzw. Ausfallsicherheit einzelner Server zu realisieren?

Selbst WebApps sind Clusterfähig, solange man sich an den Standard hält (zB. muss die Session vollständig serialisierbar sein, kein Zugriff per java.io.File aufs Dateisystem, etc. pp.).

Denke das deamon aber Performance sparen will und solche Serialisierungen vermeiden will. Ein zustandsloser Server sozusagen der vom Client den Zustand mitbekommt.

 

[JanHH]

Aber dann bleibt eigentlich wirklich nur noch hidden-Input und POST, oder? Was ich ja gar nicht so schlimm finde.. einziger Nachteil, "Link in neuem Tab öffnen" geht nicht.