ALWNULL und READE

[Ottersberg]

Moin,

ich bin da heute auf etwas gestoßen. Wir wollen Temporal Table nutzen und einige der systemgenerierten Werte brauchen NULL als erlaubten Wert. Die Programme brauchen also ALWNULL(*USRCTL). In der Doku von READE haben ich heute diesen Block gesehen:

If a file is defined as update and the N operation extender is not specified, occasionally a READE operation will be forced to wait for a temporary record lock for a record whose key value does not match the search argument. Once the temporary lock has been obtained, if the key value does not match the search argument, the temporary lock is released.In most cases, RPG can perform READE by using system support that does not require obtaining a temporary record lock to determine whether there is a matching record. However, in other cases, RPG cannot use this support, and must request the next record before it can determine whether the record matches the READE request.
Some of the reasons that would require RPG to obtain a temporary lock on the next record for a READE operation are:

the key of the current record is not the same as the search argument
the current record is not the same as the requested record
there are null-capable fields in the file
ALWNULL(*USRCTL) was specified for the module
the file has end-of-file delay


Ich verstehe daraus, dass ein Programm mit ALWNULL(*USRCTL), bei READE jetzt bei jedem Datensatz erst einen Satzlock braucht um festzustellen, dass der Satz nicht dem Schlüssel entspricht. Habe ich das richtig verstanden?

[BenderD]

... was immer das Problem sein sollte, warum mühst Du Dich in neuem Code mit Altlasten ab? Anders formuliert; Warum nimmst Du nicht SQL (auf eine View, nie auf die Table, versteht sich)? Das entkoppelt Deine Anwendung von der Datenbank, was entscheidende Vorteile verschafft!!!

D*B

[Fuerchau]

If a file is defined as update and the N operation extender is not specified, occasionally a READE operation will be forced to wait for a temporary record lock for a record whose key value does not match the search argument.
the key of the current record is not the same as the search argument

Dieses Verhalten war aber schon immer so und hat mit deinem NULL-Problem nichts zu tun.
Der READE macht da nun mal immer einen Lock (außer bei EOF).
Nur wenn der Schlüssel nicht passt, erfolgt ein Unlock und setzen des EOF.

Willst du das so nicht, benötigst du einen READE(N) und wenn nicht EOF einen zusätzlichen Chain für die nun nötige Sperre.
Per SQL läft das ja im Prinzip genauso:

Select .... where ....
macht keinen Sperre. Erst der spätere Update macht dann eine Sperre, was nun durchaus zu konkurierenden Updates führen wird wenn es denn konzeptionell nicht berücksichtigt wird.

Ausnahme entsprechend mit Commit.Modus sowie "Select ... for update".

[Ottersberg]

If a file is defined as update and the N operation extender is not specified, occasionally a READE operation will be forced to wait for a temporary record lock for a record whose key value does not match the search argument.
the key of the current record is not the same as the search argument


Ich habe mich beim Lesen so sehr auf den Punkt mit dem ALWNULL fokussiert, dass ich das gar nicht gesehen habe. Das wusste ich noch nicht. Vergesst das ich gefragt habe.