Hallo zusammen,

ich verwende Hibernate 3.1 in einer Rich Client Anwendung.
Diese Anwendung basiert darauf, dass meine Datenobjekte über mehrere GUI-Elemente paralell zugänglich und editierbar sind.

Z.B. lädt eine Editor-Oberfläche A die Kunden-Entität mit der Kundenummer 0815 aus der DB und schließt die Session. Eine andere Editor-Oberfläche B lädt ebenfalls dieselbe Kunden-Entität 0815 aus der DB und schließt die Session.

Beide Editoren besitzen dieselbe logische Entität 0815, aber unterschiedliche Objekte (Instanzen) davon.

Bei eingeschaltetem optimistischem Locking durch automatische Versionierung kann Editor A sein Objekt speichern und die Entität bekommt eine neue Versionsnummer. Somit besitzt Editor B aus DB-Sicht eine veraltete Version der Entität und es wird eine Exception geworfen, wenn B sein Objekt speichern möchte.

Solche Probleme habe ich zuhauf, da meine GUI (Eclipse Rich Client Platform) darauf basiert über viele Views, Editors, Wizards, etc. gleichzeitig Zugriff auf das Datenmodell zu bieten.

Wie kann ich dieses Problem lösen?

Hat jemand eine Idee. Wäre super!!!

mmmhhhh, auch wenn ich mir grade nicht so wirklich ein Szenario vorstellen kann, in dem 2 Editoren untersch. Instanzen des gleichen Entity innerhalb einer Anwendung modifizieren müssen, mal ganz losgelöst von der Technik betrachtet: sehr viele Möglichkeiten gibt es da ja nicht. Entweder einer sichert zuerst und der andere bekommt mitgeteilt das sein Objekt nicht mehr gültig ist/verwirft die Änderungen oder beide arbeiten an unterschiedlichen Teilen und man führt entsprechend die Änderungen zusammen.

OK, ich hab versucht, das etwas einfacher und unabhängig von Eclipse - allgemeingültig eben - darzustellen. In Wirklichkeit sieht die Sache wie folgt aus...

In meinem Fall ist es eine Eclipse View und ein Eclipse Editor. In der View habe ich in einer Baumstruktur (TreeViewer) alle Kunden dargestellt und bei Doppelklick auf einen Kunden öfnet sich ein Editor zum Bearbeiten dieses Kunden. (ähnlich der Navigator oder Package Explorer View in der Eclipse IDE)

Wenn ich jetzt Änderungen in der View vornehme (z.B. Umbenennen oder Verschieben des Kunden in eine andere Kundenkategorie), aber gleichzeitig bereits der Editor dieses Kunden offen ist, habe ich schon das erwähnte Problem.

Sowohl View als auch Editor wollen ihr Kundenobjekt speichern, besitzen jedoch unterschiedliche Hibernate-Sessions. Was nun?

Trotzdem Danke für Deine Antwort. Freut mich, dass ein Newbie hier nicht allein gelassen wird. ;-)

Und beides in die gleiche Hibernate session reinmachen?

Wäre eine Idee, aber wie soll das realisiert werden? Dann müsste ich für die komplette Anwendung eine einzige riesige Session offen haben, da ich ja nie weiß, wann der User welche View und welchen Editor öffnet.

Das habe ich so noch in keiner Anwendung gesehen und die Hibernate-Reference weißt ausdrücklich daraufhin, dass eine Session-Instanz nicht über längere Zeit (z.B. wenn auf eine Eingabe von der GUI gewartet wird) offen gehalten werden soll.

also ich kann das falsch sehen ... aber ich glaube kaum, dass das ein Problem ist, welches Du nur daher hast, weil Du Hiberante einsetzt ;-)

Von daher würde ich mir generell überlegen, wie ich damit umgehe, wenn man über eine View Daten eines Models ändert, was ebenfalls über eine andere View (dem Editor) angezeigt wird.
Stichwort: MVC, ohne mir da jetzt genauere Gedanken darüber gemacht zu haben.
Auf jedenfall muss sich eine View (z.B. der Editor) nach der Änderung aktualisieren.

Und wenn Du das dann im Griff hast, sollte es eine Kleinigkeit sein, die Daten mittels Hibernate zu persistieren. Das Problem hättest Du ja auch, wenn Du Deine SQLs selbst schreiben würdest.

gtx
curio

Ja, das ist fast richtig. ;-) Mit Hibernate wird das ganze nur noch verschärft, weil ich bei manuellen SQLs besser trennen kann, welche View welche Datenfelder (Attribute/Spalten) ändert.

Hibernate beruht jedoch üblicherweise auf POJOs, die z.B. über DAOs stets als unteilbare Einheit gespeichert werden, weshalb Konflikte bereits auftreten, wenn zwei Views nicht einmal dasselbe Datenfeld ändern, sondern nur auf demselben POJO arbeiten.

Prinzipiell gebe ich Dir aber voll recht. Es ist eine allgemeine Modellierungsfrage. Mich wundert nur, warum nicht noch mehr dieses Problem haben. Gerade im Umgang mit Hibernate sollte dieses Problem doch schon tausendmal diskutiert worden sein.

Naja, vielleicht kann ich auch nur nicht mit der Suchfunktion umgehen. ;-)

Hi,

ich sehe da mehrere Möglichkeiten:

- du lässt die Hibernate Session offen, bis alle deien Viewa der Meinung sind, das geschrieben werden kann. Sessions sind leichtgewichtig, d.h. eine Session lange offenzulassen ist eigentlich kein Problem, wenn du die DB Connection unterbrichst und bei Zugriffen wieder geziehlt reconnectest. Die Tx bleibt bis zum Ende offen.

- Du machst die Hibernate Session für jedem Zugriff auf und zu und arbeitest mit detached Objects - allerdings auf allen Views mit den gleichen (==) Objekten. Lesenswert dazu ist session.lock, session.update, session.merge

- Du verwendest eigene Viewobjekte und mergest die Änderungen dann jeweils mit den persistenten Objekten


Gruß,
Micha

@JavaSchorsch
Nimm's mir bitte nicht übel ... aber anhand einer View zu entscheiden, welche Teile eines Datensatzes ich aktualisiere ... neeee, davon halte ich gerade mal gar nix ;-) Das gibt doch früher oder später den schönsten Datensalat.
Daher bleibe ich mal dabei: Wenn das Modellierungsproblem (vielleicht mal in einem "MVC"-Forum fragen) gelöst ist, ist es der Rest auch.
Ich würde in jedem Fall, egal ob Hibernate oder nicht, nur komplette Datensätze schreiben und das nicht abhängig von irgendeiner VIEW machen. Da kommt man früher oder später ja in Teufels Küche ;-)

Lieber ein sauberes Design ... dann wird der Rest auch einfacher. Nicht böse gemeint, aber ich denke damit kommst Du schneller ans Ziel, als jetzt etwas hinzufrickeln, was Du später sicherlich bereuen wirst ...

@jerger
Ich fürchte, wenn ich die Connection zur DB unterbreche, bleibt da mit Sicherheit keine Transaktion offen ... oder ich habe manche Dinge komplett falsch verstanden. Oder Dich jetzt gerade ;-)

gtx
curio

Das wird wohl die sauberste Lösung sein, was mich aber letztlich wieder zu curios Einwand bringt. Es ist wohl schlicht und ergreifend ein generelles Synchronisationsmodell MVC betreffend.

Die beste Lösung bei einer kleineren Anwendung mit wenig Daten wäre wohl, in der Eclipse-Anwendung ein zentrales Datenmodell zu halten, auf das alle Views zugreifen. So wäre sichergestellt, dass alle dieselben Instanzen (==) besitzen und das Problem wäre gelöst.

Nur leider benutze ich ja eine Datenbank, weil ich viele Daten habe. Und diese jedes Mal komplett aus der DB zu laden und zentral im Speicher zu halten ist natürlich bescheuert. Es muss also jede View selbstständig die gerade benötigten Objekte direkt aus der DB laden und somit sind die Objekte der einzelnen Views halt nicht mehr dieselben (==). :-(

@curio: Junge, was meinst Du, wie mir das Bauchschmerzen gemacht hat in den letzten Tagen. Ich merke ja selbst, dass das letztlich in Teufels Küche enden muss. Deshalb will ich ja die kritischen Fragen im Vorfeld klären und ein sauberes Design haben. ;-)

hehe :)
Man darf ja auch nicht vergessen, sofern man mit gleichen Instanzen (==) arbeitet, dass man auch hier eine Stufe dazwischen braucht. Denn nur weil ich im Editor den Namen des Kunden ändere, darf das natürlich nicht sofort eine Aktualisierung meiner anderen Views bedeuten ... zumindest nicht, solange ich nicht auf einen Speichern-Knopf gedrückt habe ;-)

Von daher würde ich mir vielleicht überlegen sowas wie "DataChangeListener" oder dergleichen einzuführen, an denen man sich dann mit "addDataChangeListener(this, Kunde.class)" registrieren kann und mitbekommt wenn sich der Kunde geändert hat. Im Luxus-Fall bekommt man die aktualisierte Kunden-Instanz gleich mit ... ansonsten lad ich halt nach.

Oder wie auch immer ;-)

gtx
curio

Ein weiterer Punkt, der an Dich geht! ;-)

Die Listener sind übrigens bereits in Planung. Bin da nur noch nicht so sicher, wie weit ich die ausbauen soll...

@curio: Upsi, da hab ich wohl daneben geklickt. Sorry. Dafür bekommst Du dann halt nen Credit für Deinen ersten Beitrag! ;-)