Naps: Schleife unterbrechen

Hi,

gibt es eine Möglichkeit in einer Schleife eine Pause einzulegen?

Ich würde gerne in der Schleife einen AJAX Request machen aber immer zuerst die Antwort abwarten.

MfG
Naps

  1. Lieber Naps,

    gibt es eine Möglichkeit in einer Schleife eine Pause einzulegen?

    nein, JS verfügt über kein sleep(). Du kannst aber in der Schleife eine Art Timeout setzen, nach dessen Zeit andere Anweisungen abgearbeitet werden (AJAX funktioniert im Grunde so). Die Schleife selbst läuft selbstverständlich weiter.

    Ich würde gerne in der Schleife einen AJAX Request machen aber immer zuerst die Antwort abwarten.

    Dann musst Du das ohne das "A" in AJAX machen und den Request nicht a-synchron senden. Die Schleife wird aber trotzdem nicht unterbrochen, sondern läuft indessen weiter.

    Was willst Du denn _eigentlich_ erreichen, für das Du das "Anhalten einer Schleife" als die notwendige und beste technische Lösung hältst? Welchem Zweck dienen die AJAX-Requests, und warum sollte in der Schleife selbst das Ergebnis abgewartet werden, anstatt auf das Ergebnis an anderer Stelle (im CallBack) zu reagieren?

    Wenn Du das erklären kannst, dann könnte ich Dir vielleicht bessere Ratschläge geben.

    Liebe Grüße,

    Felix Riesterer.

    --
    ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
    1. Lieber Naps,

      gibt es eine Möglichkeit in einer Schleife eine Pause einzulegen?

      nein, JS verfügt über kein sleep(). Du kannst aber in der Schleife eine Art Timeout setzen, nach dessen Zeit andere Anweisungen abgearbeitet werden (AJAX funktioniert im Grunde so). Die Schleife selbst läuft selbstverständlich weiter.

      Ich würde gerne in der Schleife einen AJAX Request machen aber immer zuerst die Antwort abwarten.

      Dann musst Du das ohne das "A" in AJAX machen und den Request nicht a-synchron senden. Die Schleife wird aber trotzdem nicht unterbrochen, sondern läuft indessen weiter.

      Was willst Du denn _eigentlich_ erreichen, für das Du das "Anhalten einer Schleife" als die notwendige und beste technische Lösung hältst? Welchem Zweck dienen die AJAX-Requests, und warum sollte in der Schleife selbst das Ergebnis abgewartet werden, anstatt auf das Ergebnis an anderer Stelle (im CallBack) zu reagieren?

      Prinzipiell geht es um eine ziemlich Zeitintensive Datenbank Abfrage. Ich habe ca 100 000 000 Datensätze die abgearbeitet werden müssen.

      Da ich aber zwischendurch gerne Rückmeldung über den derzeitigen Stand haben möchte, dachte ich mir ich laufe einfach die Schleife durch und gebe dann die Rückmeldung der DB Abfrage aus. Per GET Parameter limitiere ich die Abfrage.

      Denke ich da komplet falsch?

      MfG
      Naps

      1. Ich habe ca 100 000 000 Datensätze die abgearbeitet werden müssen.

        Und die sind alle in einer Webseite, von der aus sie an einen Server gesendet werden? Die Webseite soll so lange warten bis 100 Millionen Requests durch sind?
        Ich glaube da gibts waws grundsätzliches zu verbessern :-)

        1. Ich habe ca 100 000 000 Datensätze die abgearbeitet werden müssen.
          Und die sind alle in einer Webseite, von der aus sie an einen Server gesendet werden? Die Webseite soll so lange warten bis 100 Millionen Requests durch sind?
          Ich glaube da gibts waws grundsätzliches zu verbessern :-)

          Nein sind sie natürlich nicht. Aber wenn ich das Ganze rein über PHP mache, kann ich nur sehr lange davor sitzen und warten oder? So weit ich weiß kann ich hier nichts zwischenzeitlich ausgeben oder?

          1. Aber wenn ich das Ganze rein über PHP mache, kann ich nur sehr lange davor sitzen und warten oder? So weit ich weiß kann ich hier nichts zwischenzeitlich ausgeben oder?

            Wenn du eine Ausgabe siehst musst du aber genauso lange drauf warten. Irgendwann tritt ein Timeout auf und deine Aktion ist unterbrochen.
            Was soll es überhaupt werden, ist das was einmaliges das nur du machst oder soll ein Kunde oder sonst jemand das starten? Der wartet sicher nicht so lange.
            Wenn es eine Wartungsarbeit an der DB ist, würde ich das ganz anders lösen als über eine Webseite.

            1. Aber wenn ich das Ganze rein über PHP mache, kann ich nur sehr lange davor sitzen und warten oder? So weit ich weiß kann ich hier nichts zwischenzeitlich ausgeben oder?
              Wenn du eine Ausgabe siehst musst du aber genauso lange drauf warten. Irgendwann tritt ein Timeout auf und deine Aktion ist unterbrochen.

              Eben nicht, da ich das Ganze ja aufteile. Ich würde dann z.B. sehen dass das Script gerade bei Datensatzt xxx ist.

              Was soll es überhaupt werden, ist das was einmaliges das nur du machst oder soll ein Kunde oder sonst jemand das starten? Der wartet sicher nicht so lange.
              Wenn es eine Wartungsarbeit an der DB ist, würde ich das ganz anders lösen als über eine Webseite.

              Nein nicht einmalig. Die Wartezeit dazwischen wäre auch egal, solange es eine Rückmeldung gibt, dass etwas passiert.
              Es ist nur für mich, aber da ich es mehrmals machen muss wäre der o.g. Ablauf von Vorteil.

              MfG
              Naps

              1. Tach!

                Ich würde dann z.B. sehen dass das Script gerade bei Datensatzt xxx ist.

                Jetzt erzähl doch mal das Szenario etwas genauer, nur das Problem, ohne einen Lösungsansatz zu berücksichtigen. Bisher entnahm ich, du hast eine Menge Datensätze zu bearbeiten (Problem) und lässt die paketweise per im Browser gestartetem Script abarbeiten (Lösungsansatz)? Und dann musst du jedes Paket per Hand anstoßen, so dass die ganze Geschichte nicht mal unbeaufsichtigt laufen kann (Nachteil eines solchen Lösungsansatzes)? Wenn das Anstoßen des nächsten Paketes automatisch erfolgt, ist das nur geringfügig besser.

                Ich denke, du solltest die Abarbeitung komplett auf dem Server laufen lassen. Ein im Browser gestartetes Script sollte dabei lediglich den aktuellen Stand der Datenverarbeitung abfragen. Diese Information sollte sich aus dem kleiner werdenden Auftragsstapel oder dem größer werdenden Erledigungsstapel mit einem simplen Count ermitteln lassen. Natürlich ist das nicht in jedem Fall anwendbar. Wenn zum Beispiel der Steuersatz aller Produkte geändert werden soll, dann gibt es die zwei Stapel nicht. Man könnte höchstens zählen, wieviele Dateinsätze mit dem einen und mit dem anderen Wert existieren. Das ist jedoch unter Umständen eine teuere Operation, die den eigentlichen Vorgang bremst. Hat man lediglich den Preis mit eingearbeitetem Satz, dann ist selbst das nicht anwendbar. Aber irgendwo einem Zählwert hinschreiben, den man dann (konkurrierenden Zugriff beachtend) ausliest, sollte eigentlich immer gehen.

                Wenn gar keiner der Vorschläge auf dein Szenario passt, dann: siehe erster Satz.

                dedlfix.

                1. Tach!

                  Ich würde dann z.B. sehen dass das Script gerade bei Datensatzt xxx ist.

                  Jetzt erzähl doch mal das Szenario etwas genauer, nur das Problem, ohne einen Lösungsansatz zu berücksichtigen. Bisher entnahm ich, du hast eine Menge Datensätze zu bearbeiten (Problem) und lässt die paketweise per im Browser gestartetem Script abarbeiten (Lösungsansatz)? Und dann musst du jedes Paket per Hand anstoßen, so dass die ganze Geschichte nicht mal unbeaufsichtigt laufen kann (Nachteil eines solchen Lösungsansatzes)? Wenn das Anstoßen des nächsten Paketes automatisch erfolgt, ist das nur geringfügig besser.

                  Ich denke, du solltest die Abarbeitung komplett auf dem Server laufen lassen. Ein im Browser gestartetes Script sollte dabei lediglich den aktuellen Stand der Datenverarbeitung abfragen. Diese Information sollte sich aus dem kleiner werdenden Auftragsstapel oder dem größer werdenden Erledigungsstapel mit einem simplen Count ermitteln lassen. Natürlich ist das nicht in jedem Fall anwendbar. Wenn zum Beispiel der Steuersatz aller Produkte geändert werden soll, dann gibt es die zwei Stapel nicht. Man könnte höchstens zählen, wieviele Dateinsätze mit dem einen und mit dem anderen Wert existieren. Das ist jedoch unter Umständen eine teuere Operation, die den eigentlichen Vorgang bremst. Hat man lediglich den Preis mit eingearbeitetem Satz, dann ist selbst das nicht anwendbar. Aber irgendwo einem Zählwert hinschreiben, den man dann (konkurrierenden Zugriff beachtend) ausliest, sollte eigentlich immer gehen.

                  Wenn gar keiner der Vorschläge auf dein Szenario passt, dann: siehe erster Satz.

                  An das hatte ich gar nicht gedacht, dass ich mir einfach nur die fertigen anzeigen lassen könnte. Habe es jetzt auch so gelöst.

                  MfG
                  Naps

                  1. Om nah hoo pez nyeetz, Naps!

                    Du bist doch nun auch eine ganze Weile dabei und müsstest deshalb an den Antworten erkennen, dass Vollzitate hier nur störend wirken. Dieses Forum lässt sich für jeden so konfigurieren, dass der komplette Thread in einem Rutsch gelesen werden kann.

                    Matthias

                    --
                    Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Mett und Mette.

                    1. Hallo,

                      Dieses Forum lässt sich für jeden so konfigurieren, dass der komplette Thread in einem Rutsch gelesen werden kann.

                      ja, aber das ist nicht einmal ein zugkräftiges Argument. Denn in der Einzel-Posting-Ansicht ist ein Vollzitat genauso lästig, wenn es zum Erkennen des Zusammenhangs nicht nötig ist.

                      Ciao,
                       Martin

                      --
                      Zwei Mäuse treiben's miteinander. Sagt der Mäuserich: "Hoffentlich ist nicht wieder alles für die Katz."
                      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    2. Du bist doch nun auch eine ganze Weile dabei und müsstest deshalb an den Antworten erkennen, dass Vollzitate hier nur störend wirken. Dieses Forum lässt sich für jeden so konfigurieren, dass der komplette Thread in einem Rutsch gelesen werden kann.

                      *schäm* kommt nicht wieder vor :)