Ankündigung

Einklappen
Keine Ankündigung bisher.

aufbau einer dynmischen website/ähnlich einer partnerbörse

Einklappen

Neue Werbung 2019

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

  • #31
    Achso,jetzt habe ich das verstanden.Der Admin würde also die veralteten Profilinfomationen freischalten und gleich danach würden diese aber wieder vom User überschrieben,obwohl der Admin später auf "freischalten" geklickt hat.

    macht eigentlich auch mehr sinn, da der user ja selbt schuld ist,wenn er nochmal nach korrigiert und deshalb wieder auf den unteren platz in der admin-bearbeitungswarteschlage rutsch.

    Kommentar


    • #32
      Hi,

      bezügliche der parallelen DB-Verarbeitung wären Optimistic / Pessimistic locking die passenden Suchbegriffe für dich.

      Beim optimistic locking wir der Datensatz versioniert (zusätzliche Spalte mit fortlaufender Nr.), so dass du beim Speichern feststellen kannst, ob er zwischenzeitlich verändert wurde und ggf. darauf reagierst.

      Kommentar


      • #33
        Zitat von BlackScorp Beitrag anzeigen
        es geht nur darum, dass mit den transaktionen du steuern kannst, wer als erster daten verändern darf
        Das regelst du aber definitv in einer Webanwendung nicht mit dem Code den du gepostet hast. In einer Webanwendung ohne entsprechende Mechanismen ist nur entscheidend wer das Formular als letztes absenden und damit evtl. änderungen überschreibt.

        Kommentar


        • #34
          Zitat von erc Beitrag anzeigen
          Das regelst du aber definitv in einer Webanwendung nicht mit dem Code den du gepostet hast. In einer Webanwendung ohne entsprechende Mechanismen ist nur entscheidend wer das Formular als letztes absenden und damit evtl. änderungen überschreibt.
          so wie ich das in der mysql doc verstanden habe, ist der eintrag für updates gesperrt wenn du SELECT FOR UPDATE ausführst, wenn jemand während der auswahl updaten will, kommt die abfrage in eine Queue und wird nach dem freigeben der row abgearbeitet.

          admin würde SELECT FOR UPDATE und nach dem UPDATE dann transaktion commiten, dann wird queue abgearbeitet. so habe ich das verstanden
          apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

          Kommentar


          • #35
            Jetzt bin ich verwirrt, wo hängts den bei dir? Locks werden spätestens mit dem Ende der Datenbankverbindung freigegeben. Für ein Formular per HTTP brauchst du ein Request um es zu laden und ein Request um es zu speichern. Wenn zwei zeitgleich den selben Datensatz bearbeiten, werden die Daten des ersten der speichert, von dem überschreiben der zuletzt speichert.
            Bildlich (erstes Beispiel): http://de.wikipedia.org/wiki/Verlorenes_Update
            Dabei musst du aber separieren, das ist nicht automatisch das was man als lost update bei einer Datenbank versteht. Ok, eigentlich schon, aber eigentlich auch nicht. Das Problem liegt dabei das die Datenbank verbindungsorientiert arbeitet und eine Webanwendung stateless. Die Lösungen die die Datenbank für solche Probleme bietet funktionieren immer nur innerhalb eines HTTP Request, nicht über mehrere. Bei mehreren Requests bist du auf dich selbst gestellt.
            Bei einem Formular per HTTP musst du dich also selbst um das Locking kümmern. Da kannst du dann natürlich das Verhalten nachbauen. Z.B. der Datensatz kann nur immer von einen Client zum bearbeiten geöffnet werden, oder beim Speichern wird gerpüft ob es zwischenzeitlich änderungen gab.

            Kommentar


            • #36
              ich hab mich jetzt ein wenig mit dem thema beschäftigt und bin zum schluss gekommen, dass ich das Problem über eine eigene Locking tabelle lösen werde,die vor dem Bearbeiten abgefragt wird und das Bearbeiten nur zulässt,wenn der Datensatz nicht von einem anderen Nutzer benutzt wird.
              So wie das "erc" auch schon so ähnlich vorgeschlagen hat.

              Kommentar


              • #37
                Vielleicht sollte erst mal die eigentlich Applikation stehen, bevor Du Dich mit solchen - wirklich erstmal unwichtigen - Details aufhälst.

                Mal ganz abgesehen davon: Wenn der Admin eine veraltete Information freischaltet, wird die nächste Änderunge des Benutzers eh freischalten müssen, da diese Prozesse ja sequentiell und nicht parallel ablaufen.

                Kommentar


                • #38
                  ja das kann sein,ich verhaspel mich gerne mal in details und komm so ins Stocken.Aber mir ist das ganze jetzt schon wieder etwas klarer vor augen. vielen dank

                  Kommentar

                  Lädt...
                  X