Threads

In i5/OS, an application process can also consist of one or more threads. By default, a thread shares the same commitment definitions and locks as the other threads in the job. Thus, each thread can operate on the same unit of work so that when one thread commits or rolls back, it can commit or rollback all changes performed by all threads. This type of processing is useful if multiple threads are cooperating to perform a single task in parallel.

In other cases, it is useful for a thread to perform changes independent from other threads in the job. In this case, the thread would not want to share commitment definitions or lock with the other threads. Furthermore, a job can use SQL server mode in order to take more fine grain control of multiple database connections and transaction information. A typical multi-threaded job may require this control. There are several ways to accomplish this type of processing:

• Make sure the programs running in the thread use a separate activation group (be careful not to use ACTGRP(*NEW)).
• Make sure that the job is running in SQL server mode before issuing the first SQL statement. SQL server mode can be activated for a job by using one of the following mechanisms before data access occurs in the application:
  • Use the ODBC API, SQLSetEnvAttr() and set the SQL_ATTR_SERVER_MODE attribute to SQL_TRUE before doing any data access.
  • Use the Change Job API, QWTCHGJB(), and set the 'Server mode for Structured Query Language' key before doing any data access.
  • Use JAVA to access the database via JDBC. JDBC automatically uses server mode to preserve required semantics of JDBC.

When SQL server mode is established, all SQL statements are passed to an independent server job that will handle the requests. Server mode behavior for SQL behavior includes:

• For embedded SQL, each thread in a job implicitly gets one and only one connection to the database (and thus its own commitable transaction).
• For ODBC/CLI, JDBC, OLE DB, and .NET, each connection represents a stand-alone connection to the database and can be committed and used as a separate entity.

For more information, see the SQL Call Level Interface (ODBC) book.

The following SQL support is not threadsafe:

• Remote access through DRDA®
• ALTER PROCEDURE
• ALTER SEQUENCE
• ALTER TABLE
• COMMENT
• CREATE ALIAS
• CREATE DISTINCT TYPE
• CREATE FUNCTION
• CREATE INDEX
• CREATE PROCEDURE
• CREATE SCHEMA
• CREATE SEQUENCE
• CREATE TABLE
• CREATE TRIGGER
• CREATE VIEW
• DECLARE GLOBAL TEMPORARY TABLE
• DROP
• GRANT
• LABEL
• REFRESH TABLE
• RENAME
• REVOKE

For more information, see Multithreaded applications in the Programming topic of the iSeries Information Center.