design issue: datensatz lange locken?

[Mr.Radar]

Hi,

folgende Situation: DB postgresql, ORM hibernate.

problem: der user ruft ein panel zum ändern der werte eines datensatzes auf. Da das ganze ein multi client system (1-5 clients ca.) wird, könnte dieser datensatz ja inzwischen geändert worden sein.

frage: wie würdet ihr vorgehen? den datensatz einfach beim aufruf des panels locken, und erst nach klick auf "speichern" oder "abbrechen" (oder nach timeout) wieder freigeben? oder beim klick auf "speichern" den datensatz nochmals aus der db laden und auf unterschiede vergleichen? (einen lastchange-timestamp hätt ich eh in der table drin) oder überhaupt irgendeine andere lösung, auf die ich nicht komme?

 

[SlaterB]

denkbar ist jedensfalls, nichts lange in der DB blockieren, unnötig offene Transaktionen usw.,
wenn du anderen Teilnehmern eine Blockade mitteilen willst, dann erstelle eine passene Tabelle und lege darin ab, welche Daten seit wann für wie lange für welchen Benutzer aus welchen Grund gesperrt sind,

dann ist das alles nur noch ein Organisationsproblem, hat nichts direkt mit Datenbanken zu tun,
ob man Informationen anderen Usern zur Anzeige oder Änderung vorenthält kann man allgemein doch nicht beantworten,

hier im Forum ist es sicherlich so, dass wenn einer etwas eintippt, auch jemand anders Antworten posten kann oder gar ein Moderator das Thema schließt,
in empfindlicheren Anwendungen kann das ganz anders aussehen

 

[maki]

optimistic vs. pessemmistic locking, auch als offline Varianten verfügbar

Hibernate bietet von Haus aus Unterstützung für das Optimistic Locking, entweder mit Version oder Datumsfeld.

 

[Mr.Radar]

stimmt, hibernate kann das - gerade die entsprechenden seiten im wälzer gefunden. Eine frage nur dazu (das buch drückt sich hier undeutlich bzw. JPA/annotations aus): ich verwende ganz normal hibernate, allerdings mit annotations in den POJOs statt den xml-files. Wenn jetzt wegen des lockings ein update fehlschlägt, bekomm ich dann eine StaleObjectStateException oder eine javax.persistence.OptimisticLockException?

 

[maki]

}enn jetzt wegen des lockings ein update fehlschlägt, bekomm ich dann eine StaleObjectStateException oder eine javax.persistence.OptimisticLockException?

k.A. ehrlich gesagt, aber ein kleiner Unittest sollte dir die Antwort liefern können

 

[byte]

Die Hibernate Session wirft eine StaleObjectStateException. Evtl. wirft der EntityManager eine OptimisticLockException, das weiss ich aber nicht.

Eine interessante Alternative bietet hier Spring. Das Spring Framework liefert eine eigene Exception Hierarchie für Persistence-Exceptions unabhängig von der eingesetzten Implementierung: DataAccessException (Spring Framework API 2.5)

 

[Mr.Radar]

Hm, ich bin in in der Entwicklung schon eher fortgeschritten - eine Implementierung/Portierung auf Spring wäre jetzt wohl zu umständlich.

Naja, werd einfach mal einen unittest machen, und schauen was passiert.

 

[maki]

Hm, ich bin in in der Entwicklung schon eher fortgeschritten - eine Implementierung/Portierung auf Spring wäre jetzt wohl zu umständlich.

Naja, werd einfach mal einen unittest machen, und schauen was passiert.

Dazu reicht es übrigens die Version manuell zu erhören

 

[Mr.Radar]

Könnt ihr mir generell irgendeine Literatur/Tutorials/etc. zum junit-testing von hibernate-apps empfehlen? (ist ja IMHO nicht ganz trivial - mocking etc...)

 

[byte]

Dazu reicht es übrigens die Version manuell zu erhören

Bei kaskadiertem Speichern ist das aber nicht so trivial. Ausserdem kann sich die Version zwischenzeitlich um mehr als 1 erhöht haben.

 

[maki]

Bei kaskadiertem Speichern ist das aber nicht so trivial. Ausserdem kann sich die Version zwischenzeitlich um mehr als 1 erhöht haben.

Schon klar byte, wollte ihm nur einen Denkanstoss geben wie er per Unittest rausfindet, welche Exception genau geworfen wird

Könnt ihr mir generell irgendeine Literatur/Tutorials/etc. zum junit-testing von hibernate-apps empfehlen? (ist ja IMHO nicht ganz trivial - mocking etc...)

Ob "Hibernate Apps" oder "EclipseLink Apps" oder sonst eine "JPA App", testen ist fast immer gleich.
Ausser man nutzt Spring, dann wird es viel einfacher
Jedenfalls kann ich für so etwas (RDBMS beteiligt) immer DBUnit empfehlen.