SIMON

Hallo Hermann,

kann ich davon ausgehen, dass der Server-Thread sequentiell Requests bearbeitet, also nie gleichzeitig für mehrere Requests zuständig ist?

Nein, kannst du nicht. Natürlich kann der Server mehr als einen Request gleichzeitig abarbeiten. Wäre ja fatal (bzw. unheimlich langsam) wenn er das nicht könnte.
Und jetzt kommt das ABER:

Das ganze hängt vom Client ab. Wenn du am Client nur einen Thread hast und darin nacheinander mehrere Methoden aufrufst, dann erfolgt die ausführung am Server natürlich auch nacheinander. Denn Request #2 wird erst dann abgesendet, wenn Request #1 beantwortet wurde.

Das ganze verhält sich so, wie wenn gar kein SIMON zwischen Client und Server sitzen würde.

Mehrere Threads oder Clients --> parallele Verarbeitung der einzelnen Requests
Ein Client-Thread --> sequentielle Verarbeitung der Requests

Bzgl. der Session-Information: Hast du dir schon das Session-Patternm im Wiki angeschaut?!

Gruß
Alex

Hallo Alex,
ich glaube, Du hast mich falsch verstanden. Natürlich kann der Server mehrere Threads parallel abarbeiten, wäre ansonsten auch fatal, wie Du schon sagst. Es geht nur darum, ob EIN THREAD des Servers eindeutig für einen Request zuständig ist. Ich möchte gerne eine zweistufige Abarbeitung eines Requests implementieren: In der ersten Stufe wird die Session-ID validiert und mit Hilfe eines ThreadLocal-Objektes an den aktuellen Thread gebunden. In einer zweiten Stufe erfolgt dann die eigentliche Abarbeitung des Requests. Dort würde dann auf das ThreadLocal-Objekt zugegriffen, um die Session zu ermitteln. Da die 2. Stufe sehr komplex sein kann, wäre es viel Aufwand, immer die Session des Benutzers mitzuschleppen.

Zu Deiner 2. Frage: Natürlich habe ich mir das Session-Pattern angesehen. Es war Grundlage meiner derzeitigen Implementierung.

Gruß
Hermann

Ach so...

Na dann:
Der SIMON Dispatcher stützt sich auf den Executor-Service. Jeder eingehende Request wird von SIMON in diesen Executor-Service Threadpool geworfen. Welcher Thread den Request ausführt, kann ich nicht kontrollieren. Und es ist unwahrscheinlich, dass zwei Requests nacheinander denselben Thread erwischen. Schein allein deshalb, weil die Anzahl der Threads in der default-Einstellung nicht fix ist: Ein Thread nach 60sek "nicht gebraucht" tatsächlich terminiert und abgeräumt. Werden mehr Threads benötigt, werden on the fly welche erzeugt, ...

- Alex

Ok, dann funktioniert mein Ansatz. Die execute-Methode des ThreadPoolExecutors startet also die Abarbeitung meines Requests. Dort kann ich dann als erstes das ThreadLocal-Objekt mit meiner Session-ID an den aktuellen Thread anhängen und habe es dann im weiteren Ablauf zur Verfügung. Der nächste execute() macht (u.U. mit demselben Thread) dasselbe, da ist mein Request aber schon abgearbeitet.

Vielleicht erzeuge ich aber auch ein RequestInput-Objekt, welches die Session-ID enthält. Muss ich mal sehen.

Danke für die Mühe
Hermann

Jetzt versteh ich's: Du hast nur einen tatsächlichen remote-Methodenaufruf. Nur dröselt der sich auf Serverseite soweit auf, dass es aufwendig wird, die Session-Info überall mit hin zu schleifen. Deshalb das anhängen an den Thread...

kann ich davon ausgehen, dass der Server-Thread sequentiell Requests bearbeitet, also nie gleichzeitig für mehrere Requests zuständig ist?

Hätte man anders formulieren können: "Kann ich davon ausgehen, dass ein Request bis zu seiner Vollendung, exklusiv von einem Thread abgearbeitet wird?"

Antwort: Ja

Korrekt so?

Gruß
Alex