SQL/MX Programming Manual for Java

SQLJ Programming

HP NonStop SQL/MX Programming Manual for Java—523726-003

3-23

Multithreading

A multithreaded Java application can perform tasks in parallel by using Java threads. A

thread is a block of code that executes in a single process and performs a particular

task. In an HP NonStop operating system, the JVM schedules threads with the CPU in

a nonpreemptive manner and schedules a different thread only when the currently

running thread performs a nonblocking I/O operation. See Nonblocking JDBC/MX

(Nowait SQL) on page 3-26.

This subsection assumes that you already know how to create and use Java threads.

In a multithreaded Java application, you create threads by either:

•

Implementing the java.lang.Runnable interface and wrapping a Runnable

object in a Thread object

•

Extending the Thread class

As with any Java application, you can code an SQLJ application to be multithreaded.

This subsection provides guidelines for handling multiple threads in an SQLJ program:

•

Coding a Multithreaded SQLJ Program on page 3-23

•

Nonblocking JDBC/MX (Nowait SQL) on page 3-26

Coding a Multithreaded SQLJ Program

A multithreaded SQLJ program can perform SQL operations in separate threads.

By default, each execution context object has a synchronization lock. Because of the

synchronization lock, specifying a different execution context for each thread in an

SQLJ program prevents conflicts from occurring and eliminates the need to

synchronize the threads.

For a multithreaded SQLJ program, either specify an explicit execution context for

each thread or specify an explicit connection context for each thread:

•

Using Different Execution Contexts for Each Thread on page 3-23

•

Using Different Connection Contexts for Each Thread on page 3-25

Using Different Execution Contexts for Each Thread

If you use the same connection context for all threads, you should explicitly specify

different execution contexts for each thread. In SQL/MX, you can use the implicit,

default connection context with an explicit execution context. However, it is not

recommended for portability because some SQLJ run-time environments do not

provide a default connection context and because some multithreaded applications

should avoid the static variable associated with the default connection context. For

more information, see Connection Contexts on page 3-8.

Caution. Do not share execution contexts among threads in an SQLJ program. Sharing

execution contexts among threads can lead to unpredictable transactions, race conditions (that

is, conflicts when threads operate on the same data), or deadlocks.