Objekt sperren

[osiris86]

Moin,

ich hab ein Datensatz der in einer Tabelle auf der Datenbank gespeichert ist und dieser Datensatz hat ein boolsches flag (in Bearbeitung). D.h. der Datensatz ist solange für andere Benutzer nicht bearbeitbar (boolsches flag auf true) bis der Benutzer den Datensatz geschlossen hat.
So nun mein Problem, wenn jetzt durch höhere Gewalt oder was auch immer der Rechner des Benutzer den Geist aufgibt, steht der Datensatz immer noch in Bearbeitung.
Wie bekomme ich hin das nach einem Programmabbruch der Datensatz auf in Bearbeitung (false) gesetzt wird. Könntet ihr mir einen Denkanstoß geben um dieses Problem zu Lösen, wahrscheinlich denke ich mal wieder viel zu kompliziert.


Gruß & Danke schon mal

 

[SlaterB]

Transaktion (Informatik) ? Wikipedia

 

[nrg]

Das wird garnicht mal so leicht aber ist ein allgemeines Problem, womit man öfters zu kämpfen hat. Das selbe Problem gibt es bei Instanzlocks (FileLock) - da macht es nur ein PortLock sicher, weil dieses Objekt zusammen mit der JVM den Bach runter geht. Genau da ist das Problem. Wenn das Programm abstürtzt ist das noch alles für dich kontrollierbar. Gibt allerdings die JVM gezungenermaßen den Geist auf (sei es durch Stromausfall oder wie du sagst "höhere Gewalt") ist auch keine Zeit mehr für "Aufräumarbeiten". Ich kann es mir nur serverseitig durch einen seperaten Thread o.ä. vorstellen, der diese Locks auf Aktualität überprüft. Wenn es eine reine Clientinstallation ist, musst du das eben beim Ausführen des Programms machen (aber grad bei Mehrfachzugriff tippe ich auf einen Client/Server-Anwendung). Aber vielleicht gibt es dazu auch bessere Lösungen..

 

[Guybrush Threepwood]

Das Problem hatte ich auch. Ich habe mich dafür entschieden, zusätzlich zum Flag noch einen Zeitstempel zu setzen. Dieser Zeitstempel wird zusätzlich abgefragt und wenn dieser älter als z. B. 30 Minuten ist, dann wird der Datensatz wieder zur Bearbeitung freigegeben.
Wie von nrg geschrieben könnte auch ein Thread auf dem Server diese Zeitstempel überprüfen oder auch registrieren, wenn eine Verbindung verloren geht, um dann zugehörige Flags in der Datenbank zu löschen.

 

[FArt]

Locks, Heartbeat usw. bekommt man alles geschenkt, wenn man, wie SlaterB schon angemerkt hat, mit Transaktionen auf der DB arbeitet. Nur in begründeten Ausnahmenfällen sollte man das selber lösen.

 

[osiris86]

Eine Thread auf dem Application Server möchte ich vermeiden weil das der J2EE-Standard untersagt, deswegen finde ich den Ansatz von Guybrush schon sehr gut den Zeitstempel abzufragen. Oder später falls mal Zeit ist, ein JBoss Timing einbauen und per JMS den Status abfragen.

Vielen Dank für die schnellen Antworten.

 

[FArt]

Eine Thread auf dem Application Server möchte ich vermeiden weil das der J2EE-Standard untersagt, deswegen finde ich den Ansatz von Guybrush schon sehr gut den Zeitstempel abzufragen. Oder später falls mal Zeit ist, ein JBoss Timing einbauen und per JMS den Status abfragen.

Vielen Dank für die schnellen Antworten.

:autsch:

 

[SlaterB]

@tfa
wenn es sich um lose Kommunikation zwischen Server und eigentständig agierenden Clients handelt, kann ich schon verstehen dass Transaktionen nicht so praktisch sind,
der Client fordert die Daten an und macht dann lange gar nix, zumindest nichts wovon er dem Server erzählt, der Server ist in Ruhestand, hat gar keine Session offen usw.,

dann muss auch gar kein User-Absturz vorliegen, der kann einfach eine lange Mittagspause machen, dasselbe Problem,
Timeout ist dafür doch denkbar, solange der Client läuft meldet der sich alle 5 Min. (ist das ein Fachbegriff "Heartbeat"? ) , ansonsten ist irgendwann Ende mit dem Zugriff,

hat der Client normal weitergearbeitet und nur keine Netzwerkverbindung, später aber schon wieder,
dann bekommt er dann beim nächsten Ping bzw. Speichern einen Fehler, dass sein Zugriffsrecht verwirkt ist,
bzw. kann vorher dem Client bei fehlender Bestätigung durch den Server schon auf dem drohenden bzw. wahrscheinlich bereits erfolgten Abbruch hinweisen

 

[FArt]

@tfa
wenn es sich um lose Kommunikation zwischen Server und eigentständig agierenden Clients handelt, kann ich schon verstehen dass Transaktionen nicht so praktisch sind

Klar, aber dafür gibt es hier keinen Hinweis. Der TS lässt sich dazu auch nicht ein, somit ist die Lösung erst mal unverständlich. Zumindest lässt es sich mit einer Session als Context besser lösen...