Additional Considerations

This section discusses Java multithreading in the server and recursive SQLJ calls in the server.

Java Multithreading 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:

• Threads in the server run sequentially, not simultaneously.

• In the server, threads within a call die at the end of the call.

• Threads in the server are not preemptively scheduled. If one thread goes into an infinite loop, then no other threads can run.

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".

Recursive SQLJ Calls in the Server

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.

Notes: To avoid confusion, use distinct execution context instances as appropriate whenever you plan to use execution context status or control methods in code that will run in the server. Be aware that if the above example does not use distinct execution context instances, and proc2 has any method calls to the execution context instance to change control parameters, then this will affect operations subsequently executed in proc1. Update batching is not supported across recursive calls. By default, only the top-level procedure will perform batching (if enabled). This limitation can be avoided by using explicit execution context instances.

For information about ExecutionContext methods, see "ExecutionContext Methods".

Verifying that Code is Running in the Server

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:

...
if (System.getProperty("oracle.server.version") != null 
{
   // (running in server)
}
...

Note: Do not use the getProperties() method, as this causes a security exception in the server.

---