-
 Zitat von BenderD
@Baldur: zumindest die SQL Locks kriegt man über die offenen Commit Ressourcen weg, aber das bringt auch nix: dann glaubt ein Programm, dass es die Sperre hat, obwohl es sie nicht hat...
mit Gewalt geht das schon (cancel des Sperrers aus dem Job des Warters und dann automatischer retry, aber Software, die so wackelig gebaut ist, hat sicherlich keine Transaktions Sicherung und dann...
mfg
Dieter
Ich getraue mich gar nicht zu schreiben, wie verbreitet und wie lange diese sogenannte "Standard-Software" in der Branche ist. (Ursprung /36 - wen wunderts?). Auch die Branche möchte ich lieber nicht erwähnen, man würde sich wundern - oder eben auch nicht.... ;-)
PS: Danke Baldur, ich werde mich nochmals in die API's vertiefen.
Grüsse
Roman
-
Hallo,
nur Mut, sowas muss man outen, sonst wird das nie besser ))
Eine Lösungsansatz wäre auch noch einen Messagehandler an die geschädigten Jobs anzuhängen, der dann wieder die Lock Messages auswertet...
mfg
Dieter Bender
 Zitat von roman
Ich getraue mich gar nicht zu schreiben, wie verbreitet und wie lange diese sogenannte "Standard-Software" in der Branche ist. (Ursprung /36 - wen wunderts?). Auch die Branche möchte ich lieber nicht erwähnen, man würde sich wundern - oder eben auch nicht.... ;-)
PS: Danke Baldur, ich werde mich nochmals in die API's vertiefen.
Grüsse
Roman
-
Die geschädigten Job's sind doch auch von dieser Software.
Allerdings wird die Automatisierung insoweit schwierig, da das Programm nicht entscheiden darf, welcher Job denn rausfliegt.
Ausserdem, wie Dieter schon sagt, muss das Programm eine eigene Lock-Tabelle überwachen um erst zuzuschlagen wenn die Deadlock-Situation über einen längeren Zeitraum zuschlägt, sonst werden Job's unnötigerweise gekillt.
Ich glaube dies tendiert schon Richtung Fuzzy-Logic  
-
 Zitat von Fuerchau
(...)
Allerdings wird die Automatisierung insoweit schwierig, da das Programm nicht entscheiden darf, welcher Job denn rausfliegt.
Ausserdem, wie Dieter schon sagt, muss das Programm eine eigene Lock-Tabelle überwachen um erst zuzuschlagen wenn die Deadlock-Situation über einen längeren Zeitraum zuschlägt, sonst werden Job's unnötigerweise gekillt.
Ich glaube dies tendiert schon Richtung Fuzzy-Logic   
Also Jobs werden KEINE gekillt. - Es reicht schon, wenn der geschädigte (der vor seinem Schirm wartet und wartet!) per E-Mail mitgeteilt bekommt, durch wen er blockiert wird. Die können sich dann gegenseitig die Köpfe einschlagen.... :-)
Diese Lock-Situation kommt relativ selten vor. Aber wenn sie vorkommt und nicht raschmöglichst erkannt und bereinigt wird, dann kann es zeitkritisch werden und in der Folge bares Geld kosten...
Similar Threads
-
By QSECOFR-1 in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 03-08-06, 18:06
-
By Bratmaxxe in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 29-06-06, 10:29
-
By linguin in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 22-06-06, 08:39
-
By linguin in forum IBM i Hauptforum
Antworten: 10
Letzter Beitrag: 16-05-06, 12:14
-
By Hubert in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 12-05-06, 11:52
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