| 

.NET C# Java Javascript Exception

2
Architektur
RichClient - ApplicationServer - DB

Es wird potentiell durch unseren Kunden das exklusive Sperren von Ressourcen gewünscht.

Sollte der Application-Server eurer Meinung nach Stateful oder Stateless verwendet werden, sprich Sitzungen verwalten oder nicht?
News:
27.07.2011
oopexpert 455 1 8
Bei einem Stateless-Server muss der Client den Lock auf die Ressource wieder freigeben oder ein eigens entwickelter Hintergrundprozess. Bei einem Stateful-Server kann beim Beenden der Session der Lock wieder freigegeben werden. Welches Vorgehen ist präferiert die Entwickler-Community?
oopexpert 27.07.2011
Auf die Beantwortung dieser Frage war ein Kopfgeld in Höhe von 100 Reputationspunkten ausgesetzt. Das Kopfgeld wurde bereits vergeben.
2 Antworten
2
Aus meiner Sicht sollte man immer Stateless anstreben - schon weil man damit viel leichter skalieren kann. Ausserdem ist die Freigabe der Ressourcen beim Beenden der Session nicht immer gegeben - wenn kein expliziter Logout stattfindet, bei Netzwerkproblemen usw. Der Lock der Ressource würde ich wie Markus vom Server erledigen lassen - er kann die Benutzerkennung zuordnen und mit einem Hintergrundprozess die Ressource nach gewisser Zeit wieder freigeben, falls dies nicht implizit durch einen weiteren Aufruf geschieht.
02.08.2011
puls200 3,8k 7
1
Nur anhand der exklusiven Ressourcen würde ich das nicht entscheiden. Eher die Frage was in den Sessions gehalten wird und was nicht. Ressourcen würde ich nicht über Sessiondaten abbilden, sondern diese würde ich - wenn möglich - vom Applicationserver verwalten lassen. Wenn möglich Stateful-Sessions vermeiden, ansonsten kommt man gleich in die Problematik der Persistierung der Sessions.
27.07.2011
Markus Stäuble 285 7
Die Frage ist sehr allgemein gehalten, darum meine Antwort auch etwas allgemeiner
Markus Stäuble 27.07.2011
Was ist problematisch bei der Persistierung der Sessions im Bezug auf pessimistisches Locking?
oopexpert 27.07.2011

Stelle deine Server-Frage jetzt!