Ankündigung

Einklappen
Keine Ankündigung bisher.

Satzsperren in MySQL mit Javescript?

Einklappen

Neue Werbung 2019

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

  • Satzsperren in MySQL mit Javescript?

    Hallo

    ich habe ein größeres Projekt vor mir und hoffe hier mal einige Meinung zu zu hören. Ich muss ein Multiuser System in PHP/MySQL abbilden und daher benötige ich Satzsperren. Zur Zeit plane ich in jeder Tabelle ein Feld LOCK einzubauen das einen Timestamp enthalten kann.

    Wenn nun ein Satz zum bearbeiten geöffnet wird habe ich in meiner HTML Seite ein Javascript das über Ajax ständig (alle 30 Sekunden?) den LOCK Timestamp des entsprechenden Satzes aktuallisiert. Wenn nun ein anderer Client den Satz ebenfalls zum Bearbeiten öffnen will kann er dann feststellen das der Timestamp neuer wie 30 Sekunden ist und das bearbeiten verhinden.

    Jemand ne bessere Idee, Anmerkungen oder sonst einen Hinweis?


  • #2
    Habe ich letztens ebenso gemacht.. Allerdings allgemeiner mit einer eigenen Tabelle für sogenannte Tasks. Ein Task ist z. B. das bearbeiten eines bestimmten Datensatzes. Dadurch wird das System flexibler.

    Kommentar


    • #3
      Also auf Javascript zu setzen, finde ich schon im Ansatz falsch. Und auch das Zustandspolling garantiert nicht, dass Deadlocks verhindert werden.
      --

      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


      --

      Kommentar


      • #4
        Hallo Starocotes,

        in diesem Fall bieten sich die Features von MySQL in Kombination mit einem AJAX-Service in PHP an, der die Anfragen genau wie die Logik der bisherigen Applikation verarbeitet und an eine gemeinsame Datenschicht delegiert.

        Wie haben MySQL-techniken kürzlich im Thread Identity-Map-Pattern mit memcache? im APF-Forum diskutiert. Vielleicht gibt dir das ein paar Anregungen zur Implementierung.
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design before you start to write code!
        2. Discuss and review it together with experts!
        3. Choose good tools (-> Adventure PHP Framework (APF))!
        4. Write clean and reusable software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #5
          und eine weitere Idee dazu...

          Optimistisches Sperren:
          Die Zugriffsschicht verwendet die optimistische
          Sperrstrategie: Ein Datensatz wird für die Bearbeitung zunächst
          nicht gesperrt. Arbeiten mehrere Benutzer gleichzeitig auf demselben
          Datensatz, wird die Änderung des Benutzers akzeptiert, der als erster
          speichert. Die Zugriffsschicht weist Änderungen der anderen Benutzer
          zurück. Sie erkennt Konflikte dabei anhand eines Versionszählers.
          Zitat aus: "DEN OBJEKTRELATIONALEN GRABEN ÜBERWINDEN:
          EINE DATENBANKZUGRIFFSSCHICHT FÜR .NET"
          haller_OS_4_03.pdf www.objektspektrum.de
          Dazu muss jede Tabelle beispielweise um die Spalten
          - createtime TIMESTAMP
          - modifytime TIMESTAMP
          - versionid INT

          ergänzt werden.

          Grüße
          Thomas

          Kommentar


          • #6
            Zitat von thomas_w Beitrag anzeigen
            [..]
            gefällt mir gar nicht.
            Denk dir, du wärst Anwender. Hast vllt n Haufen eingetippselt und dann wird dir gesagt, du kannst es nicht speichern, weil der Record gesperrt ist.
            Da ärgerst du dir den Arsch ab.
            Und dies kann auch später nicht eingetragen werden, weil die Änderungen des Anwenders, der speichern konnte, dann weg wären. Dann kannste deine Eingaben eigentlich direkt in die Tonne kloppen. Bestenfalls kann man einen neuen Record anlegen und die Änderungen später mergen. Aber wer soll das tun?
            Kurz: Ich halte das für extrem unpraktisch und kann mir im Moment auch keinen Fall ausdenken, wo dies "optimistische Sperren" sinnvoll sein könnte.

            Kommentar


            • #7
              Web-Applicationen sind stateless, im Prinzip kann keine Datenbanksperre gehalten werden, da am Ende des Skript ein Disconnect von der Datenbank erfolgt und damit werden automatisch alle Locks gelöst. Um trotzdem echte Datensatzsperren länger zu halten, wird bei großen Projekten ein Application-Server dazwischen geschaltet.

              Frage:
              Ein Anwender liest mehrere Datensätze "SELECT .. FOR UPDATE" (Locks werden erzeugt) und geht dann in die Pause, gehen dann alle anderen Benutzer auch zwangsläufig in die Pause, wenn diese ebenfalls diese Daten bearbeiten (UPDATE) möchten und das Programm "hängen" bleibt? Dies ist ein beliebtes Thema...

              Grüße
              Thomas

              Kommentar


              • #8
                Zitat von thomas_w Beitrag anzeigen
                Web-Applicationen sind stateless, im Prinzip kann keine Datenbanksperre gehalten werden, da am Ende des Skript ein Disconnect von der Datenbank erfolgt und damit werden automatisch alle Locks gelöst. Um trotzdem echte Datensatzsperren länger zu halten, wird bei großen Projekten ein Application-Server dazwischen geschaltet.
                was genau unterscheidet denn ein dazwischen geschalteter Application-Server von der Application selbst?
                Falls ich das richtig verstehe, können Datensatzsperren nur von der Datenbank selbst vorgenommen werden.

                Zitat von thomas_w Beitrag anzeigen
                Frage:
                Ein Anwender liest mehrere Datensätze "SELECT .. FOR UPDATE" (Locks werden erzeugt) und geht dann in die Pause, gehen dann alle anderen Benutzer auch zwangsläufig in die Pause, wenn diese ebenfalls diese Daten bearbeiten (UPDATE) möchten und das Programm "hängen" bleibt? Dies ist ein beliebtes Thema...
                Du schriebst ja selbst, daß das Script sich beendet, da hängt also kein Programm. Das einzige, was hängt, sind die gesperrten Records. Das würde ich über ein Timeout lösen, d.h., nach 30 Minuten oder so wird der Record wieder freigegeben. Sollte der Anwender dann doch noch seine Änderungen abgeben, geht's eben nicht mehr, weil der Record nicht mehr von ihm reserviert ist, das ist dann wie im wirklichen Leben.
                Sollte es dennoch möglich sein, so muß halt ermittelt werden, ob der Record seit seinem Update-Abruf anderweitig verändert worden ist.
                Zwar möglich, aber irgendwo an dieser Stelle muß man den schwarzen Peter dem User zuschieben und an sein Verantwortungsgefühl appellieren, dies o.a. eben nicht zu tun (das ist dann der schwierigste Part von allen)

                Kommentar

                Lädt...
                X