NestedException(EJB + JPA) / Mehrbenutzer Anwendung

[pl4gu33]

hey,...

also eigentl. sind das 2 verschiedene Themen aber ich wollt nicht extra 2 Beiträge dafür auf machen daher frage ich einfach mal in einem Thread

Also erst einmal zur Nested Exception... ich teste mich gerade mit EJB / JPA voran nun hab ich das Problem, dass die "EntityExistsException" (z.b. wenn man etwas einfügen will, was es schon mit der ID gibt) in einer RollbackException versteckt ist, diese wiederum in einer EJBException steckt.

Mir geht es nun darum, wie man solche Exceptions nun am Besten behandelt. Im Moment mache ich das so, dass ich im Catch- Block die oberste Exception fange und dann per getCause() so tief gehe bis ich bei meiner Exception bin und dann diese noch mal mit "instanceof" überprüfe. Das klappt auch soweit aber gibt es dafür noch eine geschicktere Lösung, solche NestedExceptions zu behandeln?

--------

Frage 2 (Mehrbenutzer):

Nehmen wir an, wir haben eine Webanwendung, die Personen in einer einfachen Tabelle anzeigt, diese man auch bearbeiten kann. Beim Aufruf der Seite wird eine Liste aller Personen aus der Datenbank geladen und angezeigt. So weit, so gut. Nun meine Frage,... wie stellt man nun am Besten sicher, dass nicht ein anderer User in der Zeit das Objekt was man bearbeitet hat, gelöscht oder eben selber verändert hat ?

Mir fallen zu dem Thema jetzt Sperren ein, obwohl die Sperren ja eigentl. nicht wirklich relevant sind, da man ja nach der Anzeige nicht die ganze Zeit ne Transaktion auf hat und zum Speichern der Änderung eine neue Transaktion macht.

Oder was ich im Moment mache, ich schaue, ob das Objekt noch besteht und führe es dann zusammen.

Wenn man das Thema weiterführt könnte man auch noch eine zweite Tabelle Wohnort dazu nehmen, welcher bei der Person in einer Liste angezeigt wird, wie stellt man nun z.b. sicher, dass nicht ein anderer User in der Zeit einfach den Wohnort in der Datenbank löscht und wenn man diesen dann verknüpfen will bzw. Persistent machen will bei der Suche keinen Wohnort hat, der so heißt, wie man ihn ausgewählt hat.

Ich hoffe ihr hab soweit verstanden, worauf ich hinaus will

Ihr könnt mir auch gerne Links posten, wenn ihr kein Bock habt zu lange Texte zu schreiben
danke schon mal für eure Hilfe im vorraus.

 

[maki]

1. Mir fällt da auch nix besseres ein.
2. Klingt nach einem Fall für, optimistic oder eben pessemistic

 

[pl4gu33]

mm,... okay, das Problem dabei ist, wenn man aber die Transaktionen zu macht, bzw. seine Persistenz Objekte in Buisness Objekte wandelt, wird das mit dem Sperren nicht mehr richtig funktionieren, wenn ich das nun richtig verstehe. Da man ja nicht mehr in einer Transaktion mit den Persistenz Objekten arbeitet. Da bleibt einem ja fast nix anderes übrig, als selber zu prüfen, ob das Objekt noch besteht oder ?

 

[maki]

Auch das selber prüfen ist nicht sicher, was passiert wenn zwischen dem prüfen und dem neuanlegen ein anderer user schneller war?

Verstehe aber ehrlich gesagt nicht ganz was du meinst... hier mal ein (über-)vereinfachter Umriss vom Locking (ändern von bestehenden Daten):
- Optimistic Locking: Pro Speichern der Entity wird ein Zähler hochgesetzt (zB. version genannt), wenn du speichern willst und merkst dass der Zähler nicht mehr übereinstimmt, weisst du, dass jemand anderes schneller war und kannst deine Änderungen verwerfen und den Usern informieren dass er mit veralteten Daten gearbeitet hat und alles nochmal machen muss.

Vorteil: Ist sehr einfach zu implementieren, jede DB "unterstützt" das (macht die Anwendung selber und ist deswegen unabhängig von der DB), wird von JPA und Implementierungen von Haus aus unterstützt (@Version)
Es skaliert schön weil nix wirklich gesperrrt werden muss.

Nachteil: Der User muss in im Falle eines Konfliktes alles nochmal machen, ist kein großes Problem wenn die Arbeitsschritte überschaubar bleiben.

-Pessemistic Locking: Die DB sperrt den Datensatz in der DB (beachte die verschiedenen Isolationsstufen), kein anderer kann den Datensatz ändern, keine echten Konflikte.

Vorteil: Die DB selber verwaltet die Sperre, selbst mehrere Anwendungen können auf derselben DB arbeiten.

Nachteil: Komplex, abhängig von der DB, skaliert schlecht und kann zum Flaschenhals werden.

Meist wird Optimistic Locking eingesetzt.


Zum Thema EntityExistsException:
Was genau meinst du mit ""EntityExistsException" (z.b. wenn man etwas einfügen will, was es schon mit der ID gibt)"?
IDs sollten nie doppelt sein, meist lässt man dasss die JPA Implementierung oder die DB IDs vergeben.

Dass von dir beschriebene vorgehen um die Ursache zu finden kenne ich bei "normalen" (also nicht PK) Unique Constraint Violations.

 

[pl4gu33]

ahhh okay, ich werde das morgen nochmal ausprobieren mit dem Locking,... hatte das mit der ID etwas anders verstanden.

Zu der Exception... jap "Unique Constraint Violations" is auch der normale Einsatz dafür. Aber in der Klasse, die ich vorgesetzt bekommen habe, wurde als Primär Schlüssel ein String verwendet, der eindeutig sein soll und wenn ein User versucht eine Person mit gleichen Namen zu speichern bekomm ich ne EntityExistsException.

danke für deine Antwort !

 

[maki]

Aber in der Klasse, die ich vorgesetzt bekommen habe, wurde als Primär Schlüssel ein String verwendet, der eindeutig sein soll

Aua... das ist ein grundlegendes Problem, würde ich als erstes ändern, IDs haben technische Schlüssel zu sein ohne fachliche Bedeutung.

 

[pl4gu33]

okay dann danke für deine Antworten
werde dann Constraints einbauen und ne vernünftige ID vergeben/generieren lassen, solang mir da keiner für auf die Füße tritt, dass ich es richtig machen will