Ankündigung

Einklappen
Keine Ankündigung bisher.

Mehrbenutzerbetrieb, Sicherstellung von Datenkonsistenz

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Mehrbenutzerbetrieb, Sicherstellung von Datenkonsistenz

    Hi,

    ich bin grad dabei mir zu überlegen, wie ich sicherstellen kann, dass in einem Mehrbenutzersystem immer die richtigen und aktuellen Daten vorliegen.
    Dazu ein Beispiel:

    Nutzer "a" ruft einen Datensatz auf und stellt fest das eine Information fehlt und entscheidet ihn zu bearbeiten.
    Nutzer "b" ruft den gleichen Datensatz auf, bevor "a" mit seinen Veränderungen fertig ist, auch b will den Datensatz formatieren und bearbeitet ihn. Jetzt führen beide nacheinander den Update durch. Die Daten desjenigen der als erstes ein Update ausführt sind weg...

    Wie kann ich dieses Problem umgehen? ich kann mir natürlich jedesmal eine art Flag setzen in einer Tabelle oder direkt bei dem Eintrag in der DB aber das sorgt immer für ein bisschen mehr Traffic.

    Außerdem bliebe dabei das Problem zu entscheiden, wann ein Nutzer fertig ist mit seiner Arbeit bzw ist es unmöglich festzustellen ob er vielleicht das Fenster geschlossen hat und der Eintrag wieder jedem zur bearbeitung zur verfügung steht.

    Habt ihr euch schonmal darüber Gedanken gemacht? Oder vielleicht so gar eine Lösung

    Hoffe ich hab das Problem ausrechend erklärt!

    Vielen Dank für eure Mühe!
    Crypi
    PostgreSQL Forum:
    www.pg-forum.de


  • #2
    http://dev.mysql.com/doc/refman/5.1/...nsactions.html


    mfg
    stf.

    Kommentar


    • #3
      Transaktionen benutze ich bereits.

      Es geht mir (jetzt) nicht darum das die Daten korrekt eingetragen werden.

      Die Problematik ist das sich jemand die Daten ansieht und während er dies tut jemand anders die Daten ändert, die erste Person ändert dann nochmals die Daten ohne zu wissen das vor ihm dies bereits geschehen ist. Damit gehen die ersten Daten verloren obwohl aus Datenbanksicht alles in Ordnung ist.

      Crypi
      PostgreSQL Forum:
      www.pg-forum.de

      Kommentar


      • #4
        Und für welchen Zeitraum soll die entspr. Tabelle denn dann für weitere
        Transaktionen gesperrt sein?? Nur so lange wie sich ein anderer die
        Daten ansieht oder...?

        mfg
        stf.

        Kommentar


        • #5
          Für den Zeitraum in dem ein anderer die Daten bearbeitet.

          Im Grunde läufts über eine Select-Abfrage:

          Select daten from tabelle where key='...';

          dann können die daten bearbeitet werden und es kommt ein Update.

          Update daten where key='..'

          Gesperrt werden müsste von Select bis Update bzw von Zeitpunkt Select + 5 Minuten (oder was auch immer), falls der Nutzer einfach das Fenster geschlossen.

          Crypi
          PostgreSQL Forum:
          www.pg-forum.de

          Kommentar


          • #6
            Hallo,
            ich könnte mir eine Lösung so vorstellen, dass wenn jemand einen Datensatz abruft, auch der aktuelle Zeitstempel übertragen wird. Und zwar von MySQL, damit auch wirklich die Abrufzeit verwendet wird.

            Code:
            SELECT NOW() AS jetzt, * FROM tabelle WHERE id = $id
            Diese Zeit wird ebenfalls ins Formular übernommen (hidden-Field). Wird das Formular abgeschickt und in die DB eingetragen, könntest du folgende Abfrage einbauen:

            Code:
            UPDATE tabelle SET lastedit = NOW(), .. WHERE id = $id AND lastedit < $jetzt LIMIT 1
            Somit würde ein Update nur durchgeführt, wenn das letzte Update älter ist als die Daten, mit denen das Bearbeitungs-Formular gefüllt wurde.

            Kommentar


            • #7
              Wenn du die Table direkt nach "SELECT ..." mit LOCK TABLES sperrst,
              umgehst du sogar die 5min Sperre, da die Tabellensperrung aufgehoben
              wird, wenn die Verbindung zum Server verloren geht.

              mfg
              stf.

              Kommentar


              • #8
                Ist doch aber alles garnicht notwendig...

                Kommentar


                • #9
                  Das wäre ja eine ähnliche Idee wie meine, allerdings würd ich dabei auch zum Kern der Sache nicht vorstoßen. Am liebsten wäre es mir, wenn das Eintragen der "Flag" von der DB übernommen würde, um die Zeile zu sperren.

                  Sowas wie ein ReadOnly wäre schön

                  Crypi
                  PostgreSQL Forum:
                  www.pg-forum.de

                  Kommentar


                  • #10
                    Zitat von Zergling
                    Ist doch aber alles garnicht notwendig...
                    Ist es wohl doch!

                    Weil dieses Problem:

                    Zitat von Crypi
                    ...das sich jemand die Daten ansieht und während er dies tut jemand anders die Daten ändert, die erste Person ändert dann nochmals die Daten ohne zu wissen das vor ihm dies bereits geschehen ist...
                    besteht auch mit deiner Methode.
                    stf.

                    Kommentar


                    • #11
                      Nein, nach meinem Beispiel kann eine Datenänderung nur erfolgen, wenn die Daten seit dem Abrufen nicht geändert wurden.
                      Wenn dies doch passiert ist, schlägt die WHERE-Bedingung fehl.
                      Wo ist der Unterschied zu deiner Technik, eine technische Sperre per LOCK o.ä. für diese (ja welche Zeit denn eigentlich) einzubauen?

                      Übertreibts doch jetzt nicht mit minutenlangen Schreibsperren.
                      Wenn ichs Problem verkannt habe bitte nochmal kurz erklären

                      Kommentar


                      • #12
                        vlt so?

                        SELECT ... FOR UPDATE

                        mfg
                        stf.

                        Kommentar


                        • #13
                          Aus "select for update" bin ich auch gerade gestoßen... sieht ganz gut aus, werde damit mal rumprobieren.

                          Ich melde mich wenn ich mal ein bisschen "gespielt" hab.

                          Danke für eure große Hilfe!
                          Crypi
                          @ zergling:
                          bei deiner Methode wäre es möglich das ein Nutzer die Daten auf dem Formular ändert,dann abschickt und dann die Fehlermeldung bekommt "Daten können nciht gespeichert werden weil..."
                          Es wäre sinnvoller wenn er diese Meldung bekommt, sobald er den Datensatz aufruft.
                          PostgreSQL Forum:
                          www.pg-forum.de

                          Kommentar


                          • #14
                            @Zerg

                            Zitat von Zergling
                            kann eine Datenänderung nur erfolgen, wenn die Daten seit dem Abrufen nicht geändert wurden
                            wird schon durch interne Transaktionssicherheit der DB gewährleistet.
                            (OT nutzt Transaktionen. siehe oben)

                            Wenn ich den OT richtig verstanden habe, will er verhindern, dass Benutzer02 die
                            Daten bestimmter Rows ansieht während Benutzer01 gerade dabei ist, Daten zu
                            ändern. Benutzer 02 bekommt so u.U. 'veraltete' oder 'falsche' Daten zu sehen und
                            könnte versucht werden diese zu ändern, obwohl dies bereits Benutzer01 tut/tat.

                            @OT: Richtig??


                            Zitat von Crypti
                            Die Problematik ist das sich jemand die Daten ansieht und während er dies tut jemand anders die Daten ändert, die erste Person ändert dann nochmals die Daten ohne zu wissen das vor ihm dies bereits geschehen ist. Damit gehen die ersten Daten verloren obwohl aus Datenbanksicht alles in Ordnung ist.

                            //EDIT: zu spät...


                            mfg
                            stf.

                            Kommentar


                            • #15
                              Ja genau das meine ich!

                              was isn OT?

                              CRypi
                              PostgreSQL Forum:
                              www.pg-forum.de

                              Kommentar

                              Lädt...
                              X