|Oracle8i SQLJ Developer's Guide and Reference
This section discusses Java multithreading in the server and recursive SQLJ calls in the server.
Programs that use Java multithreading will 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 Java VM, as opposed to in client-side Java VMs:
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 may 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 may 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 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.
Be aware that if
For information about
There is a convenient way to verify that your code is actually running in the server. You can accomplish this by using the standard Java
System.getProperty() method 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: