Hallo AC'ler,

ich habe einen sensitiven Bereich in einer Table, welchen ich bei Cronjob-Start sowie bei Cronjob-Ende modifizieren würde wollen.

In der Zwischenzeit: Der Besucher soll gezielt mit seinem "update" daran warten ...

Kleiner Haken: Ich habe zwei zeitgleich startende Cronjobs (sekundengenau; eigene Threads), die auf die gleiche Tabelle losgehen würden.

Meine Fragen hierzu, da ich mir die unzähligen Beispiele rund um "lock tables" bereits durchgelesen habe:

1. Wenn Cronjob 1 im logischen Moment schneller ist und "lock tables" macht, wartet Cronjob 2 erwartungsgemäß?
2. Ein SELECT durch einen anderen Thread (= Besucher) muss ebenfalls warten ... korrekt?

Ich habe es durch exzessives F5-Hämmern (Seitenrefresh) geschafft, dass der Client bei "warm up" (Cronjob) in die Befugnisse fährt und dann dort "überschreibt" ... meine Hoffnung ist, dass ich mit einem LOCK serverseitig den Client in exakt DEM Moment (= Cornjob-Start) bändigen kann - der Client soll die neue Information bekommen, die der Cron produziert (ist kein Cache-Problem!).

Was mich irritiert und warum ich diese Frage stelle: Die Beispiele und Handbücher sprechen immer von "threads" - also Prozessen. Da Cronjob und "Besucher" aber gar nicht im gleichen "Prozess" agieren, würde mir das LOCK daher gar nichts bringen, da ich die Sperre nicht für den Cron benötige. Schlecht formuliert oder Tatsache?!

Kurzum: Es geht nur um den "logischen Moment" ... damit in dem nichts passiert!

Nein, ein Statusflag an anderer Stelle, dass gerade was reinschreibt, ist "schlecht" ... (setzt nämlich SELECT voraus). Da muss es doch irgendwie was für die globale Verwendung an gezielt dieser `table` geben ...

- Cron 1 startet ... setzt "einen Hauch schneller" seinen LOCK!
- Cron 2 startet ... maginal dahinter - muss warten, bis Cron 1 UNLOCK ruft! Setzt dann selbst den LOCK!
- alle SELECTS bzw. UPDATES woanders her (= Besucher), müssen WARTEN!

Es spielt keine Rolle, welcher Cron zuerst LOCK macht ... !

Vielen Dank.