Ich verwende OpenJPA und habe ein Sperrproblem. Ich verstehe bereits, was eine OptimisticLockException ist und wann sie ausgelöst wird.
Aber wie kann ich damit umgehen?
Unten* finden Sie einen kleinen Absatz über die optimistischen Sperrausnahmen.
Kurz gesagt, wie kann ich den Lock Manager vollständig deaktivieren?
In meiner persistent.xml habe ich den folgenden xml-Code, aber er funktioniert nicht. Warum?
...
<properties>
<property name="openjpa.LockManager" value="none" />
</properties>
...*Laut den Wikibüchern zum Java Persistent :
Behandlung von Ausnahmen bei optimistischen Sperren
Leider sind Programmierer oft zu schlau für ihr eigenes Wohl. Das erste Problem, das sich bei der Verwendung von optimistischem Locking stellt, ist die Frage, was zu tun ist, wenn eine OptimisticLockException auftritt. Die typische Reaktion des freundlichen Superprogrammierers aus der Nachbarschaft ist, die Ausnahme automatisch zu behandeln. Er erstellt einfach eine neue Transaktion, aktualisiert das Objekt, um seine Version zurückzusetzen, fügt die Daten wieder in das Objekt ein und überträgt es erneut. Presto Problem gelöst, oder doch nicht?
Damit wird der Sinn des Schließens von vornherein zunichte gemacht. Wenn es das ist, was Sie wollen, können Sie genauso gut keine Sperren verwenden . Leider sollte die OptimisticLockException selten automatisch behandelt werden, und Sie müssen den Benutzer wirklich mit dem Problem belästigen. Sie sollten dem Benutzer den Konflikt melden und entweder sagen: "Es tut uns leid, aber es ist ein Bearbeitungskonflikt aufgetreten, und er muss seine Arbeit wiederholen", oder im besten Fall das Objekt aktualisieren und dem Benutzer die aktuellen Daten und die Daten, die er eingereicht hat, präsentieren und ihm helfen, die beiden zusammenzuführen, falls erforderlich.
Einige automatische Zusammenführungsprogramme vergleichen die beiden sich widersprechenden Versionen der Daten, und wenn keines der einzelnen Felder in Konflikt steht, werden die Daten automatisch zusammengeführt, ohne dass der Benutzer eingreifen muss. So machen es auch die meisten Software-Versionskontrollsysteme. Leider ist der Benutzer in der Regel besser in der Lage zu entscheiden, wann etwas ein Konflikt ist, als das Programm. Nur weil zwei Versionen der .java-Datei nicht dieselbe Codezeile geändert haben, bedeutet das nicht, dass es keinen Konflikt gab, der erste Benutzer könnte eine Methode gelöscht haben, auf die der andere Benutzer eine Methode hinzugefügt hat, um sie zu referenzieren, und viele andere mögliche Probleme, die dazu führen, dass der übliche nächtliche Build hin und wieder nicht funktioniert.
