Hallo.

Es ist möglich sich den First Level Cache ausgeben zu lassen und diesen dann direkt durch zu iterieren? Wenn ja, hättet ihr auch einen Tipp?

Ich möchte damit einzig ein session.refresh(first_level_cache_entity) durchführen, jedoch halt für jedes Element im Cache.

Gruß,
barthelomeo

Warum?

Auf Grund von Spezifikationen haben wir mehrere Webprojekte, die ihre eigene Hibernate Referenz nutzen. Alle Hibernate Referenzen mappen die selbe Datenbank. Diese sind nicht automatisch synchronisiert. Es wäre allerdings wichtig, die Entitäten zwischendurch zu aktualisieren.

Der First-Level-Cache sollte idealerweise jedoch kurzlebig sein, außer ihr verfolgt das Open-Session-In-View-Pattern oder einen extended persistence context. Dennoch ist mir nicht ganz klar, warum alle Instanzen im Cache aktualisiert werden sollen. Es wäre ja auch ein refresh auf dem aktuell benötigten Objekt möglich.

Alternativ könnte man auch einen Second-Level-Cache benutzen, den sich alle Applikationen teilen (cluster?) oder aber Änderungen an Objekten über JMS an andere Senden.

Die Aktualisierung aller Objekte einer Session ist nicht anzuraten, damit würde man schlimmstenfalls eine DoS-Attacke auf die eigene Datenbank fahren. ;-)

Ja wir verfolgen das Open-Session-In-View-Pattern.

Wir wollen den Refresh Prozess einmalig starten, je nach Bedarf eines Admins. Stell dir folgendes Szenario vor. Ein Admin geht, warum auch immer über eine separate Oberfläche auf die DB, sei es myphpAdmin, MySQL Workbench etc und editiert die DB. Davon bekommt die Hibernateschicht nie was mit. Wie soll es möglich sein, nun einem speziellem Hibernateobjekt zu sagen: Refresh dich? Da wir das einfach und allgemein halten wollen, war die Idee: Einmalig alles zu aktualisieren.

Das mit dem Refresh auf ein einzelnen Objekt habe ich auch probiert. Vor einem update zB macht es kein sinn, da die modifizierten Änderungen überschrieben werden. Bei einem refresh nach einem update, waren die Werte in der DB schon überschrieben. Kann auch sein, dass ich etwas falsch gemacht habe.

Wie habe ich das bisher gelöst?
Anstatt alles zu refreshen, habe ich die First-Level-Cache einfach gecleart mit session.clear(); Das scheint mir eh, rein logisch, performanter zu sein. So werden nur nach bedarf die Objekte neu erzeugt und nicht alle schon einmal erzeugten. Das Endergebnis ist das selbe: Refreshte Entitäten ;)

Zum Second-Level-Cache
Den Second Level Cache habe ich auch kurz überlegt zu nutzen. Doch in verschiedenen Quellen entnahm ich, dass es das auch gewisse Probleme mit sich zieht und nicht auf unseren Fall passt. "Wenn Sie Daten haben, die öfter aktualisiert als gelesen werden, aktivieren Sie den Second-Level-Cache nicht, auch wenn alle anderen Voraussetzungen für das Caching zutreffen!" (Christian Bauer - Java Persistence mit Hibernate, S. 533) Nur um mal ein Beispiel zu nennen.

Für alternative Ideen bin ich offen. Man lernt ja nie aus. ;)

Angenommen, es gibt eine Möglichkeit alle Objekte zu aktualisieren: Was dann? Die GUI aktualisiert sich dadurch auch nicht automatisch was de facto dazu führt, dass sowieso z.B. vorm Speichern geprüft wird, ob ein Objekt aktuell ist oder nicht?

Oder aber, es wird beim nächsten Request neu gerendert, hierbei könnte man jedoch auch refresh auf den angezeigten Objekten aufrufen. Schön wäre das auch nicht, da man hierbei definitiv viel Traffic zur DB erzeugen würde. Aber das könnte man tunen, indem man irgendwo (z.B. per MBean) ein flag setzt, welches anzeigt, ob ein refresh überhaupt nötig ist.

Wenn du session.clear() verwendest, musst du bedenken, dass dann Referenzen auf alte Objekte nicht aktualisiert werden, session.get() liefert dir dann neue Objekte.

Insgesamt ist es nicht einfach so pauschal eine Lösung zu finden, vielleicht wäre eine Art Listener-Pattern eine Möglichkeit?

Da es geplant war die Aktualisierung von der GUI her durchzuführen, wäre ein neuladen der Seite am Ende der Funktion zu implementieren.

Ja das mit den Referenzen ist mir bewusst. Es ist auch im Moment eher die einfachste, schnellst zu implementierende Möglichkeit gewesen.

An ein Observer/Listener Pattern habe ich auch schon gedacht, nur dass müsste direkt auf der DB angesetzt werden. Immerhin bringt es mir leider nichts, es auf der Hibernate Schicht aufzusetzen, da es ja mehrere gibt und somit jede Instanz einer Hibernateschicht ihr eigenes unabhängiges Obeserver Pattern hätte. Was dazu noch kommt, dass es auch abgefangen werden müsste, wenn man von anderen Tools die DB administriert. Genau hier hören meine Kenntnisse auf. Ich wüsste nicht, wie man auf einer DB direkt einen Observer implementiert.
Daher habe ich angefangen Optimistic Locking zu implementieren. Das läuft auch soweit. Bei Zeiten habe ich vor das noch zu erweitern. Das beinhaltet immerhin ein Flag zur Aktualisierung. Jedoch fehlt der automatische Aktualiserungsschritt DB -> Hibernateobjekt. Bisher kann ich nur Hibernateobjekt -> Stale Objekt State? -> Refresh

Was für eine DB ist es denn? Ich könnte mir soetwas vorstellen wie: Ein Trigger sendet die Ids der geänderten Tupel in ein MessageTopic (JMS). Jede Applikation die interessiert ist, Änderungen mitzukriegen, registriert eine MDB, die wiederum die Listener in der GUI benachrichtigt.

Es ist eine MySQL 5.0.77 Datenbank. Hm, wenn das funktionieren würde, wäre das ja schon mal ein guter Ansatz. Jedoch gestehe ich, kenne ich mich bisher nicht damit aus, daher kann ich nicht beurteilen, ob das MySQL kann. Weißt du das zufällig? Bzw. welche Datenbanken, die du kennst, können dies?

Ich musste so etwas auch noch nie realisieren, normalerweise würde man in einem solchen Fall auch den Admins eine Art FE zur Verfügung stellen. aber Oracle kann es und Postgres mit Sicherheit auch.