-
 Zitat von dschroeder
Zu unserem selbstgebauten Locking: Da wird einfach in einer Locktabelle für jeden zu sperrenden Datensatz ein Eintrag mit dem Dateinamen und der Record-ID des Datensatzes erzeugt. Jedes Programm, das den Datensatz sperren möchte, guckt vorher in dieser Tabelle nach, ob der Satz bereits von einem anderen Job blockiert wurde. Das Verfahren ist simpel und funktioniert natürlich nur, wenn sich alle an dieses Verfahren halten. Ein Programm, das dieses Verfahren nicht beachtet und sich einfach auf physische Datenbanklocks verlässt, erkennt so eine "logische" Sperrung natürlich nicht.
... noch eine Bemerkung zu eurem Sperrverfahren:
Ich würde hier Satzsperren und Prozesssynchronisation gedanklich voneinander trennen. Satzsperren sind kurz andauernd (Milllisekunden) und dienen der Transaktionskontrolle, das macht die Datenbank automatisch und hier dürfen keine lang andauernden (mehar als eine Bildschirmtransaktion) Sperren auftreten.
Prozesssynchronisation benötigt lang andauernde Sperren, bis ein anderer Prozess fertig ist. Hierunter fallen z.B.: Reisebuchungen, Verwaltung von Versicherungsverträgen können dazu gehören, auch Bestellungen mit Reservierungen können dazu gehören; in dieselbe Kategorie fallen auch etliche Batchprogramme (während Verbuchung A läuft, dürfen manche Prozesse nicht laufen), insbesondere bei Parallelisierung (wg. Speed).
Euer Ansatz mit einer Datei, die Sperren verwaltet ist erst mal OK. Ich würde das allerdings optimieren.
- Sperre setzen durch schreiben eines Sperrsatzes unter commit in einer ACTGRP, die nie commited wird.
- Sperre freigeben durch löschen des Sperrsatze.
- bricht das irgendwo ab, macht die Datenbank einen automatischen Rollback (hackt jemand die Stromzufuhr durch, beim nächsten IPL)
- zentralisiert wird das in einem SRVPGM, das als einziges die Sperrdatei benutzt und dazu aufgerufen wird. Beim CRTSRVPGM ACTGRP(NOCOMMIT) verwenden.
- kann eine Sperre nicht erteilt werden, sendet die entsprechende Procedure eine Abbruchmeldung.
- optional kann man noch einen wait Parameter in die Schnittstelle aufnehmen, bei immed sendet man eine Escape Message - ansonsten blockiert man den aufrufenden Prozess (lässt ihn warten).
Die Sperrdatei wird mit recordwait immed angelegt.
D*B
Similar Threads
-
By Lucky662 in forum NEWSboard Programmierung
Antworten: 11
Letzter Beitrag: 28-07-22, 08:30
-
By LoCal in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 22-07-05, 10:15
-
By gize in forum NEWSboard Drucker
Antworten: 6
Letzter Beitrag: 22-02-05, 06:48
-
By Miles in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 13-10-03, 19:47
-
By Arbi in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 22-09-01, 10:13
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks