Announcement

Collapse
No announcement yet.

Exklusive Datensatzbearbeitung durch User

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Exklusive Datensatzbearbeitung durch User

    Hallo, <br>
    ich suche eine Inspriation um folgende Problematik gelungen(?) abzubilden.<br>
    System:
    =-=-=-=<br>
    MS SQL 2000
    Windows Server 2003<br>
    Problem:
    =-=-=-=<br>
    In einer Datenbank dürfen bestimmte Datensätze jeweils nur von einem Benutzer bearbeitet werden. Andere Benutzer dürfen den Datensatz dann nur ansehen. Dies gilt solange, bis der erste Benutzer den Datensatz wieder verlässt oder ggf. speichert.<br>
    Beispiel:
    =-=-=-=<br>
    User1 greift auf Datensatz1 zu. Der Datensatz wird für alle anderen Benutzer nur noch "lesend" zugänglich. Wird der Datensatz1 von User1 verlassen, kann der Datensatz wieder von einem anderen Benutzer bearbeitet (lesend u. schreibend) bearbeitet werden.
    Der schreibende Zugriff gilt also für den ersten Benutzer, der den Datensatz wieder öffnet oder neu anfordert.<br>
    Lösungsvariante:
    =-=-=-=-=-=-=-=<br>
    Eine Lösungsvariante die ich mir vorgestellt habe war, dies über eine separate Tabelle zu lösen. In der Tabelle würden die derzeit bearbeiteten (schreibener Zugriff) Datensätze mit ihren PK_IDs und den jeweiligen Benutzern hinterlegt.<br>
    Schwäche:
    =-=-=-=-=<br>
    Bei obiger Variante sehe ich aber folgende Problem:
    - Anderen Benutzer müssten den Datensatz erneut abfragen um zu erfahren ob der Datensatz wieder freigegeben wurde.
    - Sollte der Client die Verbindung abbrechen (abstürzen) ohne, dass der Code für die Freigabe des Datensatzes erfolgt, wäre dieser solange gesperrt bis der User sich am System neu anmeldet und das Programm die Säuberung vornimmt.
    (Dieses Problem könnte eventuell durch einen Trigger in der DB oder einer Routine vom Server, die beim Logout des Clients ausgelöst würde, gelöst werden).
    <br>
    Vielleicht hat einer von euch eine gute Idee oder schon Erfahrung mit dieser Problematik. <br>
    Danke

  • #2
    Ich denke mal, der Ansatz mit einer eigenen Tabelle, in der die Record-ID eingetragen wird, ist schon mal ein guter Weg. Ich würde dann aber noch ein Zeitfeld dazuhängen, dass der sperrende Client zB alle 5 Sekunden auf den aktuellen Zeitstand des Servers setzen muss.
    Die Abfrage bei einem gesperrten Record könnte dann vom wartenden Client ebenfalls alle 5 Sekunden automatisch erfolgen, dabei wird ID und Aktualität des Zeitstempels geprüft. Diese Lasten sind sowohl für die Client-CPU wie für das Netzwerk und auch für den SQL-Server unrelevant. Und sollte sich die Applikation des sperrenden Clients aufhängen, würde eben der Zeitstempel nicht erneuert und damit wäre selbst bei Connection-Pooling der Record nach 5 Sekunden wieder frei für andere.
    Das ließe sich dann sogar noch weiter ausbauen mit Überwachung durch Trigger und Agent, die einen Client, der schon zu lange sperrt, einfach killen (eine böse Erziehungsmaßnahme für Anwender, die nicht hören wollen) .

    bye,
    Helmu

    Comment


    • #3
      Müsste sowas nicht "nativ" mit Locking udn Transkationen machbar sein

      Comment


      • #4
        Danke hwoess für die gute Anregung. Ich werde diese Idee wahrscheinlich umsetzten. <br>
        @Roger Bieri
        Ich arbeite mich gerade in das Thema Locking ein.
        Werde also noch sehen, ob ich dort eine entsprechende Lösung finde.
        <br>
        Ich meld mich nochmal, wenn ich mehr weiß. Evtl. mag in der Zwischenzeit ja jemand noch n paar Ideen äußern. :

        Comment

        Working...
        X