SQL + Datensatzsperre

[B.Hauser]

Wenn nun ein neues Programm mit Transaktionssicherheit entwickelt wird und hier entsprechende Satzsperren durch Updates entstehen, kann es sein, dass der Rest der Anwendung Probleme bekommt, da diese grundsätzlich nicht mit Satzsperren rechnet und deshalb dort zu Fehlverhalten führt wenn eine Satzsperre auftritt (keine Bezugszahl für Satzsperre, Programmabruch mit CPF-Meldung).

Diese ERP-Anwendung rechnet an keiner Stelle mit einer Satzsperre, da diese, wie gesagt, über Flagfelder (mittels Filehandler-Programmen) bearbeitet werden.
Es gibt bestimmt noch andere Anwendungen die ein ähnliches konzeptionelles Verhalten verwenden.

Wie gesagt, wir haben es getestet und bezüglich dieser Anwendung für unmöglich befunden.

Sofern die Standard-Satzwartezeit nicht verändert wurde ist diese 60 Sekunden, d.h. bevor die Alt-Anwendung auf Satz-Sperre/Fehler läuft wird eine volle Minute versucht auf den Satz (sofern die Datei unter Update definiert ist) zuzugreifen. ... eine verdammt lange Zeit.

Es hat auch niemand gesagt, dass die Verwendung von Commitment Control einfach ist. Da muss man sich schon überlegen, wie groß eine Transaktion wird und ob man diese nicht ggf. stückeln muss, da sonst nichts mehr läuft.
So schön es auch wäre 1000 Aufträge mit jeweils 500 Posititonen in einer Transaktion auszulagern, Bewegungen und Bestände zu aktualisieren die entsprechenden Sätze für die Buchhaltung zu generieren usw. ... da läuft nichts mehr!

Jede Transaktion, die länger als ein paar Sekunden (was schon sehr hoch gegriffen ist) benötigt würde ich überdenken wollen.
Vielfach muss an solchen Stellen auch das ganze Konzept neu überdacht werden, z.B. anstatt einen Auftrag komplett in einer Transaktion zu verarbeiten, muss pro Auftrags-Position eine Transaktion erfolgen. Wenn alle Positionen ordnungsgemäß verarbeitet wurden, wird ein entsprechender Status im Auftrags-Kopf gesetzt, der besagt, dass eine Weiterverarbeitung möglich ist.

... aber wie gesagt jedem das seine!

Birgitta

[BenderD]

... doch, doch - durchaus - die Verwendung von Commit ist einfach!
Am Besten sieht man mal bei denen über den Zaun, die das am längsten machen und das sind die Mädels und Jungs von der Wassergekühlten Fraktion. Unter MVS hat man da einen Transaktionsmonitor (z.B.: CICS - gibts sogar auf der AS/400, aber keiner nimmts). Selbiger steuert dann sowohl die Bildschirme, als auch die Datenbank Operationen und sorgt dafür, dass eine Datenbanktransaktion nie länger als eine Benutzertransaktion (:= Ausgabe eines Bildschirms mit Eingabemöglichkeit für den Benutzer) dauern kann. Damit beantwortet sich auch die Frage mit den 1000 Aufträgen, wie von selber. Die Transaktion wird nie größer als 1 Auftrag werden, und wenn die Positionen einzeln eingegeben werden, nicht größer als eine Position, den Rest hast du ja schon skizziert.
Vielleicht sollte man da mal einen Workshop zu machen (ich würde da auch Sonderpreise für das Forum machen...).

D*B

Es hat auch niemand gesagt, dass die Verwendung von Commitment Control einfach ist. Da muss man sich schon überlegen, wie groß eine Transaktion wird und ob man diese nicht ggf. stückeln muss, da sonst nichts mehr läuft.
So schön es auch wäre 1000 Aufträge mit jeweils 500 Posititonen in einer Transaktion auszulagern, Bewegungen und Bestände zu aktualisieren die entsprechenden Sätze für die Buchhaltung zu generieren usw. ... da läuft nichts mehr!
Birgitta