Problem mit Datensatzsperrung

[Alex_winf01]

Also ich habe ein "kleines" Problem:

Anwender A lässt sich DS A mit Select anzeigen und möchte den bearbeiten. Anwender B lässt sich den DS A auch anzeigen. Nun soll Anwender B den DS A nicht überschreiben.

Der Kunde möchte jedoch nicht Hibernate und H2 unterstützt nur die Database Locking und nicht das Locking auf den einzelnen DS.

Ich habe mir das jetzt so gedacht:

In meiner Tabelle habe ich eine Spalte "inBearbeitung". Sobald der erste Anwender den DS A anzeigt, wird diese Spalte auf TRUE gesetzt. Gleichzeitig muss ich mir natürlich merken, dass dies Anwender A war, damit dieser auch ein Update durchführen kann. Anwender B kann dann zwar ein Select durchführen, aber kein Update.

[Schiller256]

Von welcher Umgebungen sprechen wir hier? Welche Größe die Datenbank(Anzahl Datensätze)?

Das mit der zusätzlichen Spalte finde ich nicht wirklich schön. Denn was machst du wenn das Programm mal abstürzt und der Datensatz als „inUse“ gekennzeichnet ist.

[Alex_winf01]

Java-Umgebung, H2 Datenbank, wenig Datensätze. Wie gesagt: Hibernate ist nicht gewollt.

EDIT: Natürlich muss das dann in einer Transaction ausgeführt werden. Entweder ganz oder gar nicht.

[Schiller256]

Mit Umgebung meine ich Desktop/Server Bereich. Wenig Datensätze ist ein sehr dehnbarer Begriff, reden wir hier von <100 oder von >500.000 Datensätzen.

Wenn hibernate nicht gewünscht ist dann wäre vielleicht noch eine selbst geschrieben Zugriffsfunktion auf diese Tabelle.

[Alex_winf01]

Auf den Clients/Server wird Windows verwendet. Wenig heisst < 4.000 Datensätze im Jahr.

Kannst Du mir ein Beispiel geben, wie eine Zugriffsfunktion auf eine Tabelle aussehen kann? Ich möchte nicht die ganze Tabelle sperren, nur den einzelnen DS.

[Schiller256]

Die Zugriffsfunktion kann ich dir nicht schreiben. Ich hatte eine an eine HashMap gedacht die dir die Primarschlüssel der bereits gelesenen Datensätze hält. Mit Hilfe dieser Map kannst du dann steuern ob ein Datensatz readonly oder writeable genutzt werden kann. Wie die Transaktion um das ganze Geschehen aussehen kann/soll da müsste ich im Moment noch etwas drüber nachdenken. Denn das ist eben nicht so ganz einfach zu entscheiden wenn ein Datensatz als readonly gekennzeichnet wurde ob er wirklich noch genutzt wird oder ob der User schon ganz was anderes macht.

Was ich mit Umgebung meine ist, ob du im Java-EE oder Java-SE Umfeld entwickelst denn da gibt es durchaus unterschiede die man beachten muss. Denn im EE Umfeld kannst du es recht schnell mit Mehrfachzugriff Probleme bekommen.

[Alex_winf01]

@ Schiller256

Also es wird eine Java-SE-Umgebung verwendet (Java 6.0).

Hash-Map hört sich mal nicht schlecht an. Durch die Mehrbenutzerfähigkeit habe ich mein Programm auf jedem Client als JAR-File liegen (die Datenbank liegt auf dem Server). Ich muss dann ja irgendwo die Hash-Map so speichern, dass jeder Anwender-Client darauf Zugriff hat. Wie kann ich das lösen?

[Schiller256]

Egal ob du nun mit einem fertigen Persistenzframework arbeitest oder dir selber was schreibst. Wirst du um eine Server Komponente nicht herum kommen. Denn nur am Server kann festgehalten werden ob ein User den Datensatz bearbeitet oder nicht. Falls der Kunde kein Hibernate will es gibt auch noch andere Persistenzframeworks die dir vielleicht weiter helfen können ohne das du das selbst etwas schreiben musst.

Ist es vielleicht möglich auf eine Datenbank zu wechseln die es ermöglicht einzelne Datensätze zu sperren? z.B. Derby ist ja bereits in Java 6 integriert.

[Alex_winf01]

Also ich verwende die Server-Komponente von der Datenbank H2 (Vorgabe vom Kunden, kein RMI, kein Hibernate oder anderes Persistenzframework). Es soll wie folgt laufen:

Anwender A schaut sich Datensatz A an. Anwender B darf Datensatz A weder lesen, geschweige denn bearbeiten oder löschen.

Hab mich jetzt umentschieden. Werde eine Tabelle anlegen, wo neben der Spalte "inBearbeitung" noch die Spalte "Anwender" enthält, der den Datensatz gerade in Bearbeitung hat. Nur dieser Anwender ist dann berechtigt, den Datensatz zu lesen, bearbeiten und zu löschen. Natürlich brauche ich Transaktionen. Falls das Programm abschmiert, wird mit Rollback alles wieder zurück geschrieben. Ich brauche auch ein Timeout, falls der Anwender einschläft oder einfach vom Rechner weggeht.

Ich muss also jeden Anwender eindeutig dem Datensatz zuordnen

[dr.dimitri]

Hi,

ich muss dir leider sagen: Es wird nicht funktionieren. Bevor ich mich hier aber in diverse Erklärungen verliere und Du dich evtl. daran machst eine eigene Transaktionssteuerung (die nie wirklich 100%ig funktionieren kann) zu entwickeln, solltest Du deinem Kunden lieber eine richtige multiuserfähige DB schmackhaft machen.

Da wären z-B. postgreSQL oder die kostenlose Oracle XE (lass auch die Finger von mysql).

Bei beiden Datenbanken kannst Du dein Problem ohne eine einzige Zeile zusätzlichen Quellcode lösen und spartst somit natürlich auch dem Kunden wieder Zeit, Geld und ehöhst so nebenbei die Wartbarkeit deines Programms (das in der Hinsicht auch korrekt arbeiten kann).

Dim

[Alex_winf01]

@ dr.dimitri

Diese Variante habe ich mit dem Kunden schon diskutiert - wird nicht gewollt. Es muss eine H2-Datenbank sein. Und warum sollte das mit Transaktionen nicht funktionieren? Hilbernate läuft auch mit Transaktionen.

[Alex_winf01]

Ach noch was: Es soll gar nicht erst so weit kommen, dass es konkurierende Updates gibt. Anwender A lässt sich Datensatz A anzeigen, Anwender B kann sich dann den Datensatz A nicht mehr anzeigen lassen. Für ihn steht auch kein select zur Verfügung.

[dr.dimitri]

Ok so seltsame Anforderungen hab ich noch nie gesehen. Ich würd mich verabschieden, denn der Kunde möchte kein IT System sondern einen Karteikartenkasten. Dort kann sich jemand eine Akte rausnehmen, die wird dann nicht mehr von anderen gesehen und kann auch nur von ihm geändert werden. Eine Datenbankgestützte Multiuseranwendung ist keine Lösung für sein Problem.

Aber mal im Ernst: Du redest von einer eigenen Locktabelle, in der Du deine Informationen hineinschreibst und deren Änderungen zurückgerollt werden soll wenn die Anwendung abgeschossen wird.

Jetzt ist es aber so, dass eine Transktion nur zurückgerollt wird wenn Sie noch nicht committet ist. Ist sie nicht committed wird sie von anderen Sessions aber nicht gesehen.

H2 "unterstützt" einen sog. Dirty Read. damit kann eine Session auch uncommittete Daten lesen was im ersten Augenblick wie eine "Lösung" für dein Problem aussieht, allerdings verwendet H2 standardmäßig Table Locking:

The database allows multiple concurrent connections to the same database. To make sure all connections only see consistent data, table level locking is used by default.

Und

If a connection wants to write to a table (update or delete a row), an exclusive lock is required.

Bedeute im Klartext: Solange eine offene Transaktion auf einer Tabelle ist, kann keine andere Transaktion in dieser Tabelle etwas ändern.

Und jetzt die Frage: Wie soll das mit der offenen Transaktion in deiner Locktabelle funktionieren, wenn mehr als ein Satz (unterschiedlich) geändert werden sollen?

Jedem logisch denkenden Menschen sollte klar sein, dass hier irgendwo ein "Problemchen" liegt.

Machst Du es mit einer anderen selbstgebauten Methode, dann hast immer das Problem, dass Du mit dem gleichzeitigen Zugriff klarkommen musst. Irgendwann werden mal zwei User gleichzeitig auf den Satz zugreifen und nichts voneinander mitbekommen. Das passiert vielleicht nur selten, aber es reicht um das Vertrauen in das Programm leicht zu erschüttern.

Im übrigen hilft da auch eine Persistenzschicht, denn die kann auch nur das unterstützen was auch die Datenbank mitmacht.

Daher meine Aussage: Das wird nicht funktionieren.

Es gibt für solche Fälle das sog. optimistische und pessimistische Locking, welches für solche Anforderungen verwendet wird um sicherzutellen, dass keine Änderungen verloren gehen. Allerdings braucht man dazu eine wirkliche Datenbank.

Dim

[Schiller256]

Das Karteikasten Beispiel ist sehr gut, du hast nur noch vergessen zu erwähnen das es eben auch Nutzer geben wird, wenn sie eine Karteikarte nicht finden genau diese wieder ergänzen werden.

Also ich kann dir auch nur Raten zeige dem Kunden die Probleme auf und sagen klar und deutlich was das bedeutet ich würde da sogar so weit gehen und sagen nein das setze ich nicht um, denn du hast das Programm dann in Wartung musst dich mit solchen und ähnlichen Problemen rum schlagen. Wie schon geschrieben hast du keine mehrere Millionen Datensätze daher sollte ein Umstellung der Datenbank kein Problem darstellen.

[dr.dimitri]

Im übrigen hilft da auch eine Persistenzschicht, denn die kann auch nur das unterstützen was auch die Datenbank mitmacht.

Es muss natürlich heißen keine Persistenzschicht.

Dim