[Erledigt] LOCK TABLES - Thread statt Table???

[Curanai]

Verehrte PHP.de-Forum'ler,

ein Fehler im heutigen Nachtlauf bescherte mir schon eine Partie NHL2005, um meinen Debuggingfrust einzudämmen. Was in der Entwicklungsumgebung (XAMPP, Win) funktioniert, läuft nicht im Live-Betrieb (Linux) ...

Vorab: Ja, es sind (mind.) zwei verschiedene Datenbanken (Cluster-Betrieb)!

Problembeschreibung, die ein Funktionsaufruf mitbringt (sinnwahrend gekürzt):

function __finalize(){
LOCK TABLES `foo` WRITE (in DB1)
SELECT * FROM `foo` WHERE [...] (in DB1)
UPDATE `bar` SET [...] (in DB2)
INSERT INTO `fehlersack` (in DB1)
DELETE FROM `foo` WHERE [...] (in DB1)
UNLOCK TABLES
}

`fehlersack` schmeißt mir nun Unruhe bringend ein "Database Error: 1100 | Table 'fehlersack' was not locked with LOCK TABLES" - aber warum sollte er gelockt sein?

Nur `foo` soll für diese Operation gesperrt werden, da dies der Bereich ist, der als "kritisch" eingestuft wird und wo während des Nachtlaufs nichts ergänzt werden oder passieren darf. Sinngem. würde aber in diesem Fall - so wie es der Befehl eigentlich sagt - nicht die Table für eine Operation eingeschränkt werden, sondern der Thread, der da arbeitet. Denn wenn dieser sich auf das "beschränkt", was vorher per LOCK ermöglicht wurde, würde das den Fehler bei gleicher Datenbank erklären ... aber eben nicht, wie es im Manual (mySQL), O'Reilly's "kurz & gut" or else steht.

Denn von der Logik her müsste er doch weiterhin in eine Table schreiben können, die eben nicht ge'LOCK't ist, oder? Es ist nur eine Reservierung für den Zugriff auf eine Tabelle eines bestimmten Threads (hier: der Cronjob) ...

Ich bitte um Augenöffnen, Steinigen oder Mitgefühl!

Danke.

[Curanai]

Schade ... aber danke fürs Lesen - ich werde eine andere Lösung erdenken.