nicht angemeldet
Hallo TS,
Da ist doch aber ein Denkfehler in der Zeitlinie, oder?
Nein.
Das System wäre extrem fehleranfällig!
Nö, funktioniert gut. Wie etwa hier im Forum zu sehen. Und es funktioniert so gut, dass es der best practice ist…
Wie kommt denn der Client an die aktuellen Daten, wenn er noch einen Reqest absetzen konnte, der auf dem Server auch noch abgearbeitet wurde, aber die Response nicht mehr entgegen nehmen konnte? Die sind dann verloren!
Ja ach! Wenn eine Antwort vom Server verloren geht, sind Daten verloren! Mach Sachen! 😉
Und wenn ich in der Sessiondatei z. B. 2 MByte gesammelt habe,
Then you're doing it wrong. Eine Session hat hier selbst bei den komplexesten Anwendungen, die ich entwickelt habe, nur ein paar Byte. REST to the rescue! 2MB State sollte niemand haben. Tatsächlich benötige ich die Session nur in Ausnahmefällen…
Eine Datenbank ist sicherlich eine passende Uniq Location für derartige Daten. Zur Not muss man sie eben auch wieder aufteilen nach Nutzerkreisen. Und wer würde den Softweareersteller überhaupt daran hindern, die Sessiondaten alle zentral auf einem einzigen Netzwerkfileserver im LAN (intrerne Zone) zu halten, auch wenn die Verarbeitung auf unterschiedlichen Hosts stattfindet?
sshfs machts doch ganz einfach möglich!
SSHFS ist so ziemlich die langsamste und fehleranfälligste Variante, die man sich einfallen lassen kann. Da sind selbst Session-Daten auf einem NFS-Share noch deutlich robuster…
Am besten aber nutzt man gar keine übers Netzwerk shared files, das hat wirklich eine Menge Pitfalls. Wenn ich nur ans file locking auf Files in einem Netzwerk-Share denke, bekomme ich schon graue Haare. Oder was machst du etwa, wenn der Server einfach mal weg ist? Netzwerk ist bei weitem nicht unfehlbar…
LG,
CK
TS