Dataset Problem mit parallelen änderungen (Speichern)

  • VB.NET
  • .NET (FX) 4.0

Es gibt 3 Antworten in diesem Thema. Der letzte Beitrag () ist von Gunngir.

    Dataset Problem mit parallelen änderungen (Speichern)

    hallo,

    Es geht um ein Programm, das Projekte in meiner Firma managen soll - und auch bereits im Einsatz in mehreren Projekten ist.
    Das Problem liegt darin, dass wenn eine Komponente angezeigt wird deren benachbarten Baugruppen auch immer angezeigt werden.
    Vorgabe: Mehrere Benutzer sollen in Zukunft die gleiche Baugruppenliste der gleichen Komponente editieren können.


    Begriffbeschreibung:
    Komponente = Parent
    Baugruppe = Children
    Ein aufruf der Komponente bezieht immer den Aufruf aller Kinder der Komponente mit ein,
    welche in einem Datagridview angezeigt werden.

    Problembeschreibung:
    User1: Aufruf der Komponente um 12:00 Uhr.
    User2: Aufruf der gleichen Komponente um 12:00 Uhr.
    User1: Veränderung von Baugruppe1, Spalte3 der Komponente + Speichern um 12:05 Uhr.
    User2: Veränderung der gleichen Baugruppe in Spalte4 + Speichern um 12:10 Uhr.

    Der User2 überschreibt mit dem Dataset automatisch die vorher gemachten Änderungen von User1.
    Die Zelle3 ist somit nicht mehr verändert, die Veränderungen von User1 gehen somit verloren.

    Ein Verlust der Daten wäre also auch extrem hinderlich bei gleichzeitiger Bearbeitung :(

    habt Ihr eine Lösung?
    willkommen in der Datenbank-Programmierung!

    Das Problem heisst "Datenbank-Konkurrenz", und dafür gibts keine Standard-Lösung.

    Es gibt verschiedene Strategien, damit umzugehen, deine derzeitige Strategie ist offensichtlich "Last-In-Wins", und solch ist manchmal ok, meist aber unbefriedigend.

    Üblicherweise implementiert man Sperr-Mechanismen, also ein User kann nicht mehr an allem, was er sieht, jederzeit herumfummeln, sondern zum Editieren eines Datensatzes geht er in einen besonderen Edit-Modus, der im Hintergrund nochmal von der Db abfragt, ob der DS ühaupt frei ist, und wenn ja, setzt er die Sperre, und kein anderer User kann mit diesem Datensatz in den Editmodus.
    Nachm Edit oder Cancel wird die Sperre natürlich wieder aufgehoben, und ausserdem muss es einen (großzügigen) Timeout geben, damit nicht evtl. Datensätze für immer gesperrt sind, falls einem User während des Editierens der Rechner abstürzt.
    Ach, und wenn der User beim Editieren den Timeout ausreizt, dann musser natürlich rausgeschmissen werden aussm Edit-Modus - vlt. gibt man ihm sogar vorher noch eine Warnung aus.

    Also es ist richtig schwierig, musste feste googeln, nach "optimistic/pessimistic lock" und so sachen.
    Manche DB-Systeme unterstützen das auch mit besonderen Timestamp-Datentypen, und evtl. kann man sogar noch mehr anne Datenbank herumkonfigurieren - kenne mich nicht gut aus.

    Zur Not schreibt man halt einfach Zeiten rein, und wickelt das Sperre-Handling komplett im Client ab (hofflich werd ich dafür jetzt nicht gehauen von richtige Db-Profis)

    Am liebsten umgeht man das Problem, wenns möglich ist, etwa, indem man jedem Benutzer nur seine eigenen Daten verfügbar macht.
    Das kann auch schwierig werden, ist aber immer noch einfacher als ein sauberes System mit pessimistic Locking (also was ich skizziert habe).
    Aber wenn deine Anforderung das nicht zulässt, dann gehts halt nicht.
    Ahoi,

    eine andere Möglichkeit wäre es noch Transactions zu verwende, wenn dein DB-System das zulässt.
    Die Änderungen kommen in eine Transaction, dann wird geprüft ob die Daten bearbeitet wurden. Dem Nutzer müsste hier vielleicht eine Info dazu gegeben werden und ob er es überschreiben oder verwerfen möchte. Dazu sollte ihm evtl. die Möglichkeit gegeben werden die anderen Änderungen nachzuvollziehen und es wird dabei wohl auch eine Versionierung notwendig werden. Sprich Tabellen, in denen du die Änderungen mit Nutzer und Zeitpunkt protokollierst.
    Grüße Manu

    Was Gott dem Menschen erspart hat, kann der Computer.
    Billy ©, (*1932), Schweizer Aphoristiker
    Quelle: www.Aphorismen.de
    danke für Eure Hilfe.

    Leider bin ich (noch) nicht tief genug im System drin, um ein solches Programm auf Transaktionen umprogrammieren zu können.

    Dann wird wohl die Variante des minimalsten Aufwands genommen : Client handelt alles, und um Falle eines Falles wird eben sich kurz über phpmyadmin auf den Server geschaltet und selbst frei geschaltet, falls ein Mitarbeiter auf die idee kommt, das Programm zu killen :)