SQL/MX Programming Manual for Java

Introduction
HP NonStop SQL/MX Programming Manual for Java—523726-003
1-6
SQLJ Versus JDBC Performance
SQLJ Versus JDBC Performance
In addition to the advantages that SQLJ offers, as described in Benefits of SQLJ on
page 1-1, you should consider performance when choosing between SQLJ or JDBC. A
choice of SQLJ versus JDBC for a Java program depends on the importance of startup
versus steady-state performance, how the application is written, and the functionality of
the application.
Be aware that you can use both SQLJ and JDBC in the same program. For more
information, see SQLJ and JDBC Interoperability on page 1-5.
Startup Performance
Startup performance is based on how long it takes a program to start running.
Startup Performance of JDBC/MX Programs
In a process instance of a JDBC program, each SQL statement must be prepared (that
is, SQL compiled) before it can be executed. If you wrote a program with performance
in mind and the statement text is constant throughout the program, each prepared
statement is cached by the application logic. Each statement is compiled exactly once
per process instance (or once per thread per process instance for a multithreaded
program).
How you prepare the SQL statements in a program also influences startup
performance. You can write a program so that the SQL statements are prepared all at
once during startup. This scenario appears as a delay before any client requests are
processed. Alternately, you can write a program so that each statement is prepared as
it is first encountered in the program. This scenario appears as an intermittent startup
during execution.
The startup time varies depending on the number and complexity of SQL statements in
a program. More numerous and complex statements in a JDBC program slow the
startup time. Although the preparation of the SQL statements is a performance penalty
only at the startup of the process, it happens every time the process starts.
Startup Performance of SQLJ Programs
In an SQLJ program, the SQL statements are compiled during development before the
application is deployed and run. The compiled SQL plans are stored in SQL modules,
just as they are in embedded SQL programs in C or COBOL. Like embedded SQL
programs in C or COBOL, SQLJ programs have no startup penalty other than when
the SQL/MX executor reads the compiled plan from the module. This penalty costs
much less than the run-time compilation of each statement. An SQLJ program is
expected to start up more quickly than an equivalent JDBC program, depending on the
number and complexity of the SQL statements.