# design issue: datensatz lange locken?



## Mr.Radar (1. Nov 2009)

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 (2. Nov 2009)

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 (2. Nov 2009)

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 (3. Nov 2009)

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 (3. Nov 2009)

> }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 (3. Nov 2009)

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 (3. Nov 2009)

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 (3. Nov 2009)

Mr.Radar hat gesagt.:


> 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 (3. Nov 2009)

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 (3. Nov 2009)

maki hat gesagt.:


> 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 (3. Nov 2009)

byte hat gesagt.:


> 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 



Mr.Radar hat gesagt.:


> 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.


----------

