PDA

View Full Version : Satzsperre



Seiten : [1] 2 3

programmer
14-06-04, 20:36
Kann mir jemand eine Lösung für das Problem "Satzsperren" bei interaktiven bzw. Batchjobs verraten.

Den File-Parameter waitrcd möchte ich aber nicht auf *nomax setzen.

Fuerchau
14-06-04, 20:54
Da gibt es keine generelle Lösung, sondern das hängt vom Anwendungsdesign ab.
Normalerweise sollte keine Satzsperre über Dialoggrenzen gehalten werden (sprich: Satz sperren und auf die Rückkehr des Bedieners von der Mittagspause warten).

Ansonsten gilt:
Fehler abfragen (Bezugszahl oder %error()) !
*NOMAX sollte man tunlichst vermeiden, denn das gibt die typischen Deadlocks.

BenderD
14-06-04, 21:00
Hallo,

optimistic locking ist angesagt. ein einfacher Weg ist:
- Feld Version in Datei aufnehmen und bei jedem Update eins hochsetzen
- UPDATE ... SET ... WHERE Key = Key and Version = Version
bei SQLCOD = 100, ist der Satz seit dem lesen verändert worden, funzt ohne jede Satzsperre

Dieter Bender

mk
15-06-04, 09:54
Hallo programmer,

ich weiß nicht wo das Problem liegt, aber manchmal
werden Satzsperren von (tollen) Dialogprogrammen verursacht.

Kleines Beispiel:
Der Pgmer schraubt mal schnell ein Subfile Pgm zusammen.
Nur leider hat er durch Copy/Paste vergessen
die Datei nur Input zu öffnen.
Also ist die Datei mit Update definiert.
Jetzt liest das Pgm die Daten. Und was passiert ? ......


Vielleicht gibt es ja solche Fälle

Gruss Michael

Wuntvor
15-06-04, 11:27
Das ist grundsätzlich ein Riesenthema.

1. Kann man natürlich programmintern den Datensatz ewig lesen, also auf die Satzsperre reagieren, aber das ist ja keine wirklich Lösung.

Grundsätzlich ist die Thematik Satzsperre im gesamten Paket zu konzipieren, was natürlich im Nachwege kaum noch zu machen ist.

Als Lösung hat sich bei mir folgendes bewährt.
1. Updates nur auf die Physische Datei
2. Logische Dateien werden nur Input eröffnet.
2. Physische Datei hat keinen Key sondern wird über die relative Satznummer gepflegt. Also sind Updates "aus versehen" nicht möglich.

Diese Logik führt dazu, daß Satzsperren nur extrem kurze Zeiten auftreten. Natürlich muss man dies koppeln mit einem Updatezähler, damit man letztlich den letzten Zugreifenden ermitteln kann und selbiges programmtechnisch abarbeiten. Im Dialog kann mann dann auf diese Satzsperre hinweisen, welche aber eben nur für Milli-Sekunden auftritt.

Unklar genug ????? :rolleyes:

Fuerchau
15-06-04, 13:11
@Wuntvor
Wenn die PF keinen Key hat, wie verwaltest du die Satznummer ?
Wie siehts aus mit REUSEDLT(*YES) oder must du immer einen RGZPFM machen (was lästig ist).
Wie sieht das ganze dann per SQL aus ?

Wuntvor
15-06-04, 13:45
Beim Lesen einer logischen Datei erhält man über die INFDS die relative Satznummer der physischen Datei. Die Satznummern sind dir dann vollkommen egal.

BenderD
15-06-04, 14:09
Hallo,

noch ein paar grundsätzliche Anmerkungen zu den Satzsperren:

Default für den record Wait sind 60 sec. das sind deutlich zuviel!!! was nach einigen Millisekunden nicht freigegeben ist, kann stundenlang gesperrt sein.

Default für den Datei Wait ist *immed, was absoluter Schwachsinn ist!!! auf eine Datei sollte man mindestens solange warten, wie auf einen Satz. Dieser Unfug verhindert die Benutzung von serialize als Sperrlevel im SQL.

Das größte Problem sind immer lang andauernde Sperren und Deadlocks (dafür braucht man den Satz Wait).

Hängende Sätze an der Benutzer Transaktionsgrenze (EXFMT) verhindert man am einfachsten mit Commitment Controll, da gibt der Commit, bzw. Rollback alles frei.

Von den Keylosen Dateien ist dringendst abzuraten, damit verhindert man Normalisierung der Daten, da man ja ohne Key nix verknüpfen kann und man nagelt sich alle Türen für Modernisierung der Anwendung zu. Fazit: so programmiert man Altlasten, die nicht sanierbar sind. (BTW hier werden Zufalls Operationen nicht verhindert, sondeern geradezu herbei programmiert).

mfg

Dieter Bender

Dieter Bender

B.Hauser
15-06-04, 15:38
Hallo,

Hängende Sätze an der Benutzer Transaktionsgrenze (EXFMT) verhindert man am einfachsten mit Commitment Controll, da gibt der Commit, bzw. Rollback alles frei.

Von den Keylosen Dateien ist dringendst abzuraten, damit verhindert man Normalisierung der Daten, da man ja ohne Key nix verknüpfen kann und man nagelt sich alle Türen für Modernisierung der Anwendung zu. Fazit: so programmiert man Altlasten, die nicht sanierbar sind. (BTW hier werden Zufalls Operationen nicht verhindert, sondeern geradezu herbei programmiert).


Noch ein paar weitere zusätzliche Anmerkungen:
Wenn man mit Commitment Control und RPG arbeitet, muss man wissen, das ein UNLOCK bzw. die Erweiterung (N) beim Chain oder Read einen Satz nicht freigibt, sondern immer nur ein Commit oder Rollback.

So schön die Commitment Control auch sein mag, sie erfordert ein zusätzliches Mass an Überlegung, nämlich wann und wo die Commits gesetzt werden. Da sind Programme schon Stunden gelaufen, haben alles blockiert, wurden abgebrochen und liefen nochmal solange bis sie beendet waren und haben dabei auch noch die Platte vollgeschrieben.
Und nur weil an irgend einer Stelle ein kleiner unschuldiger COMMIT vergessen wurde.

Der ganze Zauber mit Zugriff über relative Satz-Nr. ist spätestenfalls dann passé, wenn die Dateien mit SQL angelegt werden. SQL kennt kein REUSEDLT(*NO)! Allerdings kennt SQL (seit Release V5R2M0) ROWID oder IDENTITY COLUMNS über die eindeutige "Zähler" generiert werden können. Über beides kann ein Index gelegt werden, wodurch der Zugriff über "Relative Satz-Nr." simuliert werden kann.

Birgitta

BenderD
15-06-04, 16:21
Hallo,

einiges ist mir so selbstverständlich, dass ich nix dazu geschrieben habe. Commit Verwendung macht eigentlich nur mit embedded SQL und Schichtentrennung Spass und dann wird immer Committed bevor die Steuerung aus der Datenbank-Zugriffs Schicht nach oben geht und das war's.

Dieter


Noch ein paar weitere zusätzliche Anmerkungen:
Wenn man mit Commitment Control und RPG arbeitet, muss man wissen, das ein UNLOCK bzw. die Erweiterung (N) beim Chain oder Read einen Satz nicht freigibt, sondern immer nur ein Commit oder Rollback.

So schön die Commitment Control auch sein mag, sie erfordert ein zusätzliches Mass an Überlegung, nämlich wann und wo die Commits gesetzt werden. Da sind Programme schon Stunden gelaufen, haben alles blockiert, wurden abgebrochen und liefen nochmal solange bis sie beendet waren und haben dabei auch noch die Platte vollgeschrieben.
Und nur weil an irgend einer Stelle ein kleiner unschuldiger COMMIT vergessen wurde.

Der ganze Zauber mit Zugriff über relative Satz-Nr. ist spätestenfalls dann passé, wenn die Dateien mit SQL angelegt werden. SQL kennt kein REUSEDLT(*NO)! Allerdings kennt SQL (seit Release V5R2M0) ROWID oder IDENTITY COLUMNS über die eindeutige "Zähler" generiert werden können. Über beides kann ein Index gelegt werden, wodurch der Zugriff über "Relative Satz-Nr." simuliert werden kann.

Birgitta