Soll ich Spring Session Scoped Beans oder einen Cache wie ehcache verwenden?

Question

Wir haben eine App, die den Status beibehalten muss, damit einige Objekte, die Daten enthalten (potenziell eine Menge), von einem Client (Browser) in einer "konversationalen" Interaktion abgefragt werden können. Es wäre nicht effizient, die Daten bei jeder Anfrage neu zu laden.

Wir verwenden Spring- und Session-Bereiche, um einige sitzungsgesteuerte Daten zu verwalten. Diese neuen Bohnen wären jedoch größer.

Wäre dies eine angemessene Verwendung von Session-Scoped-Beans oder wäre ein Cache (ehcache) besser geeignet?

Wir zögern, eine Caching-Technologie zu verwenden, es sei denn, wir müssen es wirklich tun.

Der andere Faktor ist, dass die App in einem Cluster bereitgestellt werden muss. In welchem ​​Fall würden die Session-bezogenen Beans durch die Sitzungsreplikation des Anwendungsservers repliziert werden oder wäre es effizienter, ehcache zu verwenden (von dem ich glaube, dass es in einem Cluster verteilt werden kann)?

Jede Anleitung geschätzt.

Answer 1

Paar Gedanken zu diesem (Disclaimer: Ich arbeite für terracotta/ehcache ... halten, so dass im Sinne ... aber immer noch versuchen, unvoreingenommenen, hier zu sein):

1 - Gibt es redundante Daten in jede der Sitzungen? Alles, was in den Sitzungen geteilt werden könnte? Wenn ja, +1 für ehcache, um die geteilten Sachen zu speichern (weil ehcache für starke Nebenläufigkeit optimiert ist)

2 - Wie groß werden Ihre Sitzungsobjekte sein? Und wie viele gleichzeitige Nutzer erwarten Sie im stationären Zustand? (Mit anderen Worten: Wie viel Speicher müssen Sie dem Sitzungsspeicher auf Ihrem Anwendungsserver zuweisen?)

Wenn der Sitzungs-Footprint insgesamt nicht so groß ist und gut in Ihren Heap ohne GC-Probleme passt, dann verwenden Sie die Sitzung sollte eine gute Lösung sein.

Aber je größer es wird, desto größer muss Ihr Java-Heap sein ... und desto mehr müssen Sie Voodoo-Tricks verwenden, um Speicherbereinigungen und GC-Pausenzeiten in Schach zu halten. Durch die Verwendung von ehcache können Sie einige Objekte, auf die mehrere Sitzungen zugreifen können, zentral speichern ... und somit Ihren Speicherbedarf konsolidieren (derselbe Punkt wie 1) Durch die Verwendung der Enterprise-Erweiterung für ehcache (BigMemory = http://terracotta.org/products/bigmemory) können Sie Heap umgehen Einschränkungen und speichern Sie Ihre Daten Off-Heap (so viel wie nötig - 10s, 100s von GB oder mehr). Damit wird die Größe der Objekte, die sich im Speicher befinden müssen, irrelevant (solange Sie Ihrem Server natürlich RAM hinzufügen können)

3 - Für Sitzungsreplikation, App-Server wie JBOSS, Weblogic, Websphere-Unterstützung es. Auch hier geht es wieder um die Sitzungsgröße (wie viele Daten müssen über die Leitung repliziert werden). Wenn Ihre Sitzungsobjekte groß sind und Sie viele davon haben, wird es in Ihrem Cluster viel Netzwerkverkehr geben ... könnte oder könnte nicht gut funktionieren. Wenn Core-Objekte in einem verteilten EhCache-Layer für die Datenspeicherung optimiert sind und Ihre Sitzung auf ein Minimum beschränkt bleibt (d. H. Anmeldeinformationen/Authentifizierungsinformationen), würde dies meiner Meinung nach diesen Mechanismus zur Sitzungsreplikation definitiv verbessern.

Hoffe, dass hilft.