View Full Version : Nach LOCK direkt weiter
Hallo.
Wir haben in einem Programm eine DO Schleife mit einem read. Nun kommt es hier öfters mal vor, dass einzelne Sätze ein LOCK haben weil da gerade ein Benutzer mit arbeitet. Das ist ok und normal und wir haben nach dem Read eingebaut, dass er dann automatisch auf den nächsten Satz ein setll macht und dann mit dem read weiter.
Allerdings bleibt es bei dem read im Falle eines LOCKs ziemlich lange stehen und wartet, was hier nicht nötig ist. Er könnte dann theoretisch direkt weiter. Kann man irgendwie diese Wartezeit einstellen oder ganz entfernen (natürlich nur für dieses eine read - nicht systemweit)?
Gruß
Sebastian
Die Satzwartezeit wird per CHGPF festgelegt und der Default ist 60 Sekunden.
Wenn du eine kürzere Wartezeit brauchst, kannst du diese ändern, allerdings trifft es dann ja alle.
Ggf. kannst du ja per OVRDBF vor Programmauf oder Open speziell für dieses Programm die Zeit verkürzen.
Ein generelles Abschalten ist war möglich, allerdings wird das nicht funktionieren, da kein Read für einenen Update (auch per SQL-Update/Delete) auf das Ende der Bearbeitung durch andere Jobs mehr wartet. Und dies muss ja dann auch immer und überall behandelt werden.
Speziell unter Commit-Bedingungen (Transaktionen) wäre ein sinnvolles Verarbeiten von Daten unmöglich.
Auch deine SETLL-Methode halte ich nicht für zielführend, da du ja nicht weißt, auf welchen Schlüssel du wartest. Du kannst also nicht über diesen hinwegspringen, der er dem Programm nicht bekannt ist.
Aber was willst du eigentlich tun?
Bei sequentieller Bearbeitung kann man auch mit READ(N) bzw. READE(N), REDPE(N) lesen um zumindest erst mal die Daten zu lesen.
Erst bei der Entscheidung einen Satz auch zu bearbeiten macht man dann einen CHAIN und wartet auf das Ende der anderen Job-Operationen, die bei vernünftiger Programmierung, nicht allzu lange dauern.
Hallo.
Wir haben in einem Programm eine DO Schleife mit einem read. Nun kommt es hier öfters mal vor, dass einzelne Sätze ein LOCK haben weil da gerade ein Benutzer mit arbeitet. Das ist ok und normal und wir haben nach dem Read eingebaut, dass er dann automatisch auf den nächsten Satz ein setll macht und dann mit dem read weiter.
Allerdings bleibt es bei dem read im Falle eines LOCKs ziemlich lange stehen und wartet, was hier nicht nötig ist. Er könnte dann theoretisch direkt weiter. Kann man irgendwie diese Wartezeit einstellen oder ganz entfernen (natürlich nur für dieses eine read - nicht systemweit)?
Gruß
Sebastian
... rekord löffel exzem kann das nicht. Nimm SQL und Locklevel read commited, dann werden gesperrte Sätze überlesen.
D*B
Guten Morgen und danke schon mal für eure Antworten.
Die ganze Problematik betrifft unser Lagersystem. Hier haben wir alles unterteilt in LAGER, REIHE, FELD, HOEHE. Diese Werte sind blöderweise 3A (warum? keine Ahnung - Uralt). Und die Daten werden auch noch rechtsbündig geschrieben. Heisst die Werte für die Lagerorte sehen dann z.B. so aus:
LAGER ' 60'
REIHE '100'
FELD ' 15'
HOEHE ' 50'
Nun liest diese Programm einen Lagerort nach dem anderen durch und prüft hier bestimmte Werte und ändert diese unter Umständen. Sollte ein Satz gerade gesperrt sein, dann nimmt er den Wert für HOEHE, wandelt diesen in DEC 3. Addiert dann eins drauf 50 -> 51 und schriebt ihn dann mit EVALR und %char() zurück in die HOEHE Variable und macht damit ein setll. Dadurch wird beim nächsten Lagerort positioniert und dann geht das weiter. Falls HOEHE bei 999 ankommt dann wird diese auf ' 1' gesetzt und dafür dann FELD um eins erhöht. Und so arbeitet sich das Programm durch das ganze Lager.
Ist halt alles ziemlich alt und man würde es wahrscheinlich heuet anders gestalten, aber an der Grundlogik können wir da nichts mehr ändern.
Dann kannst du vor Aufruf des Programmes, über ein CLP, nur für dieses einen OVRDBF machen um die Satzwartezeit z.B. auf 5 Sekunden zu reduzieren.
Beim Lesen würde ich die N-Funktion (NoLock) benutzen wie oben geschrieben, nur beim erforderlichen Chain/Update würde dann die verkürzte Wartezeit zuschlagen.
Alles klar. Das hilft mir weiter. Vielen Dank!