SQLRPGLE Get und Set Prozeduren

[andreaspr@aon.at]

Nachtrag: die DB schließt den ODP automatisch von selbst wenn bestimmte Kriterien erfüllt werden.
Z.B. Wenn also ein ALTER TABLE abgesetzt wird, werden alle ODPs (die von SQL offen gehalten werden) automatisch geschlossen um die Sperren aufzuheben.

[Fuerchau]

Die Performance auf diese Art mit einzelnen SQL's zu lösen ist wirklich grottenschlecht.
Ich habe das für einen Kunden realisiert (es wurde als SQL-Funktion benötigt) und musste hier dramatische Einbußen hinnehmen.
In Java ist es so, dass ich einen Datensatz lese und mit den entsprechenden GetSet-Methoden nur noch auf Speicherobjekte zugreife. Ein SQL wird da nicht mehr ausgeführt.
Möchtest du das dynamisch in einer ILE-Prozedur analog betreiben musst du den Datansatz per SQL komplett einlesen und dir eine Tabelle der Feldnamen mit den Werten dazu aufbauen (das geht auch dynamisch). Dann stellst du eine "READ"-Funktion zur Verfügung, die ggf. über den Schlüssel cached und einzelne Get/Set's für die Feldinformationen.
Um es mit dem Begriff "Streng typisierte Objekte" zu vergleichen müsstest du real für jedes Feld einen namentlichen Get/Set-Zugriff generieren, also GetKundenNr/SetKundenNr, GetName1/SetName1, ...
Da ILERPG aber nicht objektorientiert ist kann man solche Ansätze eher in die Tonne drücken da sie weder performant noch hilfreich sind.
Ein simpler Zugriffshandler für komplette Strukturen mit diversen Zugriffen ist da allemal effektiver und logischer.

[dschroeder]

Eine Idee, um die möglicherweise suboptimale Performance zu verbessern, wäre es, wenn sich deine Procedure merkt, wie der Schlüssel beim letzten Aufruf war. Dann könntest du nur beim ersten Aufruf den gesamten Datensatz holen und in eine extern definierte Datenstruktur schreiben. Alle Folgeaufrufe mit gleichem Schlüssel würden dann kein eigenes SQL mehr ausführen, sondern einfach das Feld aus dem bereits geholten Datensatz zurückgeben.

Dieter

[BenderD]

... nuir mal selber vergleichen:
Variante 1: sql Zugriff pro Feld
Variante 2: sql Zugriff pro Datensatz
Variante 3: Blockfetch in ArrayDS für kompletten Auftrag mit allen Joins!!!

natürlich kann eine Serviceprogramm dann das alles in calls auf getXYZ für jedes Feld auflösen, aber die Programmierer Performance wäre katastrophal - das will doch alles getippt werden!!!

D*B

[Fuerchau]

Nun, vielleicht fällt da einem ein Generator für so einen Quatsch ein.
Zu bedenken ist ja noch folgendes:
Ein Serviceprogramm wird ja innerhalb des Jobs von verschiedenen Programmen aufgerufen.
Also nur simple Get/Set-Routinen reichen da nicht aus, da der "aktuelle" Datensatz inzwischen gewechselt sein könnte.
Wer es denn kompliziert mag, kann noch D*B's Hashtable-Implementation verwenden um je Programm per zusätzliche Id auf den jeweils gecachten Satz zuzugreifen.
Wer dabei allerdings noch den Überblick behalten will...

[BenderD]

... dafür würde ich aber (m)einen echten cache nehmen, der ist aber (noch) nicht Open Source.

[Fuerchau]

Ob ich das dann noch allgemeingültig verwenden würde...
Für die Infor-XPPS-Anwendung habe ich für einige Dateien (Tabellen, Steuerwerte o.ä.) einen internen Cache eingerichtet. Der Vorteil hier war, dass es für die Dateien Filehandler gibt und die Inhalte weitgehend statisch sind sowie nur lesend verwendet werden.
Die Programme sind per CVTRPGSRC in ILE (incl. Copy!) konvertiert.
Dann wird in einer Tabelle der Schlüssel und Datensatz beim 1. Zugriff gespeichert und mit jedem weiteren Zugriff aus der Tabelle geladen.
Dies hat die Zugriffe auf die Dateien erheblich reduziert und die Laufzeit um Faktor 20 verkürzt.
Dabei habe ich mir nicht die Mühe gemacht, die Tabellen noch zu optimieren um einen %lookupeq() zu verwenden. Aber da könnte man sicherlich noch ein paar Millisekunden rausholen.

[BenderD]

... Problem ist beim generischen cache die Keygröße, da man aber meist keine eindeutige Zuordnung braucht, genügt ein Hash (bei Kollision wird einfach verdrängt).

[Fuerchau]

Solange du dich an die AS/400-Spezifikation für Schlüssel hältst:
- max. 120 Felder
- max. 2000 Zeichen
ist doch alles i.O:-;.

[BenderD]

... die Suche über 2000 Zeichen key ist zu langsam

[Fuerchau]

Auch mit Hash? Das finde ich ungewöhnlich.