|Oracle8i SQLJ Developer's Guide and Reference
Release 3 (8.1.7)
Part Number A83723-01
This section discusses Java multithreading in the server and recursive SQLJ calls in the server.
Programs that use Java multithreading can execute in the Oracle8i server without modification; however, while client-side programs use multithreading to improve throughput for users, there are no such benefits when Java-multithreaded code runs in the server. If you are considering porting a multithreaded application into the server, be aware of the following important differences in the functionality of multithreading in the Oracle8i JServer JVM, as opposed to in client-side JVMs:
Do not confuse Java multithreading in the Oracle8i server with general Oracle server multithreading. The latter refers to simultaneous database sessions, not Java multithreading. In the server, scalability and throughput are gained by having many individual users, each with his own session, executing simultaneously. The scheduling of Java execution for maximum throughput (such as for each call within a session) is performed by the Oracle server, not by Java.
For general information about Java multithreading in SQLJ, see "Multithreading in SQLJ".
As discussed in "Execution Context Synchronization", SQLJ generally does not allow multiple SQLJ statements to use the same execution context instance simultaneously. Specifically, a statement trying to use an execution context instance that is already in use will be blocked until the first statement completes.
This functionality would be less desirable in the Oracle server than on a client, however. This is because different stored procedures or functions, which all typically use the default execution context instance, can inadvertently try to use this same execution context instance simultaneously in recursive situations. For example, one stored procedure might use a SQLJ statement to call another stored procedure that uses SQLJ statements. When these stored procedures are first created, there is probably no way of knowing when such situations might arise, so it is doubtful that particular execution context instances are specified for any of the SQLJ statements.
To address this situation, SQLJ does allow multiple SQLJ statements to use the same execution context instance simultaneously if this results from recursive calls.
Consider an example of a recursive situation to see what happens to status information in the execution context instance. Presume that all statements use the default connection context instance and its default execution context instance. If stored procedure
proc1 has a SQLJ statement that calls stored procedure
proc2, which also has SQLJ statements, then the statements in
proc2 will each be using the execution context instance while the procedure call in
proc1 is also using it.
Each SQLJ statement in
proc2 results in status information for that statement being written to the execution context instance, with the opportunity to retrieve that information after completion of each statement as desired. The status information from the statement in
proc1 that calls
proc2 is written to the execution context instance only after
proc2 has finished executing, program flow has returned to
proc1, and the operation in
proc1 that called
proc2 has completed.
To avoid confusion about execution context status information in recursive situations, execution context methods are carefully defined to update status information about a SQL operation only after the operation has completed.
For information about
ExecutionContext methods, see "ExecutionContext Methods".
A convenient way to verify that your code is actually running in the server is to use the standard
getProperty() method of class Java
java.lang.System to retrieve the
oracle.server.version Java property. If this property contains a version number, then you are running in the Oracle server. If it is
null, then you are not. Here is an example: