TS: javascript race condition

Beitrag lesen

Hello,

ob der Zugriff auf die Ressourcen nun mit Node.JS, Perl, PHP, C++ oder sonstigen Modulen auf dem Server stattfindet, ist für die Lockingstrategie irrelevant. Immer dann, wenn mehrere Clients oder Requester dieselbe Ressource zeitgleich benutzen dürfen, dann muss man unterscheiden:

  • Connected Requests: Es können Handles des Betriebssystems/Filesystems übergeben und beachtet werden. Die Zeit zwischen Holen und Wegschreiben ist extrem kurz.
  • Disconnected Requests (z. B. via HTTP): Es ist nicht sicherzustellen, dass eine permanente Verbindung aufrecht erhalten wird zwischen Holen und Wegschreiben der Daten
  • "akademischer Request" (ct), zwischen Holen und Wegschreiben der Daten liegt mehr Zeit, als man für eine permanente totale Sperre im System verwenden möchte/darf. Das kann auch bei obigen Fällen zutreffen.

Das Ganze haben Oberschlaue dann auch mal unter dem TOCTTOU-Problem beschrieben. Früher, als wir noch Deutsch reden durften, hieß das "Zeitrelevante Änderungsanforderungen an den Datenbestand" und das hat dann z. B. zur Einführung von "Beipiel für Nummernkreis"en geführt.

Jede Subsidarität verwaltet ihren Subnummern derartig streng, dass keine Doppelungen auftreten können. In Gesamtheit sind die Nummern dann wieder durch die Trennung in die Nummernkreise eineindeutig. Die Media Access Control (MAC) ist ein Beispiel dafür.  

#Kurz und gut:
Bei Zeitversatz und/oder Verbindungslosigkeit musst Du selber für die notwendige Sicherheit für die Datenintegrität sorgen.

Liebe Grüße
Tom S.

--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.