Advanced Database Feature Guide


Writing Multi-Process Applications

Although DB2 CLI supports concurrent execution of threads, IBM Smalltalk does not. However, IBM Smalltalk does allow the use of multiple Smalltalk processes which can be exploited to achieve similar results.

When to Use Multiple Processes

The most common reason to create another process in a DB2 CLI application is so that a process other than the one executing can be used to cancel a long running operation (a query for example).

Most GUI based applications use threads in order to ensure that user interaction can be handles on a higher priority process then other application tasks. The application simply delegates one process to run all DB2 CLI functions and the process method utyDB2Interrupt can be used to cancel a long running DB2 operation. If the utyDB2Interrupt message send answers with true then a DB2 function call was successfully interrupted. However, if the message send answers with false, then the process was not waiting for a DB2 CLI function call to complete or the function call could not be cancelled. If a DB2 CLI function is interrupted then it is likely that it or a subsequent DB2 CLI function may generate an exception for the SQL error "SQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014".

If the application wishes to terminate a process which uses the Advanced Database feature, it should use the utyDB2Terminate message in place of the normal terminate process message. However, if the process is terminated, the application must be careful to ensure that all resources allocated by that process, like additional connections and prepared statements, are released.

Applications that use multiple connections, and are executing statements that may take some time to execute, should consider executing DB2 statements using multiple processes to improve throughput. Such an application should follow standard practices for writing any multi-process application, most notable those concerning the sharing of connections.

Application Deadlocks

The application must be aware of the possibility of creating deadlock situations with shared resources in the database and the application.

DB2 can detect deadlocks at the server and rollback one or more transactions to resolve them. An application may still deadlock if one process is holding an application resource and is waiting for a database resource, and the other process has a lock on the database resource while waiting for the application resource.

In this case, the DB2 server is only going to see a lock, not a deadlock, and unless the database LOCKTIMEOUT configuration setting is changed, the application will wait forever.

Process Example

The following example creates a deadlock situation and then eliminates it by interrupting/canceling the dead lock. If the ifError block is removed, an SQL error of "SQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014" will be generated.

| cd conn1 conn2 sem process | 
(cd := UtyDB2DatabaseManager newConnectionDescriptor) 
databaseName: 'SAMPLE'; 
userId: 'db2admin'; 
password: 'unity'; 
autoCommit: false; 
yourself. 
conn1 := cd connect. 
conn2 := cd connect. 
sem := Semaphore new. 
conn1 executeSql: 'LOCK TABLE STAFF IN EXCLUSIVE MODE'. 
process := 
[sem signal. 
(conn2 executeSql: 'SELECT * FROM STAFF') rowsIfError: [ nil ]. 
sem signal ] fork. 
sem wait. 
process utyDB2Interrupt. 
sem wait. 
conn1 commit; close. 
conn2 commit; close. 
 


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]