Hi auch,

Das, was Du mir erklärtest, ist doch Session-Tracking, Cookie-basiert
oder eben über encodierte URLs, welche dann zusätzlich eine SessionID
enthalten. Und nichts anderes macht die Servlet-API (mit dem Unterschied,
dass das Handling komplett im Speicher erfolgt).
Aber genau das, so verstand ich zumindest n.d.p., war nicht die
erwartete Antwort auf seine Frage.

Ich kenne Tomcat nicht. Ich wollte nur skizzieren, wie man Session-Tracking
mit HTTP annähern kann - und was dabei immer noch nicht so toll ist.

Im Prinzip bräuchte man periodische Zugriffe des Clients auf den Server
unabhängig von Benutzer-Interaktionen, was aber gerade *nicht* der Sinn von
HTTP ist, welches den erzeugten Traffic gemäß der gestellen Anforderungen zu
minimieren versucht (und dafür ja sogar cacheing einsetzt).

Wie soll ich das mit dem keepalive-Signal verstehen?

Als Trigger, ein weiteres "touch" auf die Session-Datei zu machen, damit sich
ihre Lebensdauer entsprechend verlängert.

Und, ist der Zweck Performanceoptimierung, also der Hinweis an den
Server, nur bei Empfang eines solchen Signals üperhaupt in /tmp nach
einer entsprechenden Cookie-Datei zu suchen?

*Jeder* einzelne HTTP-Aufruf löst eine Kombination aus Prüfung der Session-
Datei (ggf. mit Prüfung des time stamp - auch dies kann implizit zu ihrer
Löschung und zum ReLogin führen!) und anschließendem "touch" aus (falls
die Lebensdauer der Session so definiert ist - es kann natürlich auch die
Gesamtdauer limitiert sein oder was auch immer).

"Suchen" beschreibt den Zugriff insofern etwas merkwürdig, da ja der Pfadname
aufgrund der Session-ID exakt bekannt ist, also ein direkter Zugriff genügt.

Viele Grüße
      Michael