User-Defined-Funktion mit XA-Treiber

[Atomik]

noch etwas zur Ergänzung:

Die oben dargestellte RPGLE-Routine ist natürlich etwas konstruiert und dient mir als Test um den Fehler zu lokalisieren.

Wenn ich die SETLL-Anweisung entferne, lässt sich die SQL-Anweisung mit der UDF beliebig oft aufrufen.Allerding muss ich säter natürlich in der Produktivversion des Programms aus Dateien lesen können. Von daher ist es keine Lösung einfach Dateioperationen wegzulassen.

Wenn ich einen anderen JDBC-Treiber verwende (com.ibm.as400.access.AS400JDBCConnectionPoolDataS ource) kann ich die SQL-Anweisung auch beliebig oft aufrufen. Leider befinde ich mich aber mit dem Projekt aber in einem Integrationsumfeld mit verteilten Systemen und benötige daher die Möglichkeit der vertielten Transaktionen (two-phase-commit). Daher ist die Variante ohne den XA-Treiber auch keine Lösung.

[Fuerchau]

Definiere die Datei
a) innerhalb der Prozedur mit USROPN und mach immer einen Open/Close
b) definiere die Prozedur mit CONTAINS SQL, damit Dateizugriffe im selben Thread laufen
c) verwende am besten gleich SQL in der Prozedur

[Atomik]

Vielen, vielen Dank!!! Das war der entscheidende Hinweis

[Atomik]

Definiere die Datei
a) innerhalb der Prozedur mit USROPN und mach immer einen Open/Close
b) definiere die Prozedur mit CONTAINS SQL, damit Dateizugriffe im selben Thread laufen
c) verwende am besten gleich SQL in der Prozedur

Wir haben hier eine RPGLE-Prozedur in der direkt SQL verwendet wird. Damit die Prozedur läuft mussten wir diese mit READS SQL DATA anstatt, wie von Ihnen empfohlen, mit CONTAINS SQL DATA definieren.

Laufen die Datenzugriffe mit READS SQL DATA ebenfalls im selben Thead wie der Aufrufer??? Denn dieses wollten wir ja mit CONTAINS SQL DATA erreichen. - Was auch funktionierte -

[B.Hauser]

Contains SQL oder Reads SQL hat eigentlich nichts damit zu tun, ob die Anwendung im gleichen oder einem anderen Thread läuft.

Hier ist die Definition aus der aktuellen SQL Referenz:

READS SQL DATA
Specifies that the function can execute statements with a data access classification of READS SQL DATA, CONTAINS SQL, or NO SQL. The function cannot execute SQL statements that modify data.

CONTAINS SQL
Specifies that the function can execute only SQL statements with a data access classification of CONTAINS SQL or NO SQL. The function cannot execute any SQL statements that read or modify data.

Du solltest Dir stattdessen die Option FENCED/NOT FENCED anschauen:
Hier ebenfalls ein Auszug aus der aktuellen SQL Referenz:

FENCED or NOT FENCED
Specifies whether the SQL function runs in an environment that is isolated from the database manager environment. FENCED is the default.

FENCED
The function will run in a separate thread.
FENCED functions cannot keep SQL cursors open across individual calls to the function. However, the cursors in one thread are independent of the cursors in any other threads which reduces the possibility of cursor name conflicts.

NOT FENCED
The function may run in the same thread as the invoking SQL statement.
NOT FENCED functions can keep SQL cursors open across individual calls to the function. Since cursors can be kept open, the cursor position will also be preserved between calls to the function. However, cursor names may conflict since the UDF is now running in the same thread as the invoking SQL statement and other NOT FENCED UDFs.
NOT FENCED functions usually perform better than FENCED functions.

Birgitta

[Fuerchau]

MODIFIES SQL DATA

The function can execute any SQL statement except those statements that are not supported in any function.

Scheint wohl dann eher die richtige Definition zu sein.