|Oracle8i SQLJ Developer's Guide and Reference
Release 3 (8.1.7)
Part Number A83723-01
With few exceptions, writing SQLJ code for use within the target Oracle8i server is identical to writing SQLJ code for client-side use. The few differences are due to Oracle JDBC characteristics or general Java characteristics in the server, rather than being specific to SQLJ. There are a few things to be aware of, however:
The concept of connecting to a server is different when your SQLJ code is running within this server itself--there is no explicit database connection. By default, an implicit channel to the database is employed for any Java program running in the server. You do not have to initialize this "connection"--it is automatically initialized for SQLJ programs. You do not have to register or specify a driver, create a connection instance, specify a default connection context, specify any connection objects for any of your
#sql statements, or close the connection.
There are just a few coding issues to consider when your code will run within the target server using the server-side internal driver. Note the following:
ROLLBACKstatements to implement or cancel your database updates:
If you are using any kind of XA transactions, such as Java Transaction Service (JTS) transactions, you cannot use SQLJ or JDBC
For more information about server-side JDBC and the server-side internal and Thin drivers, see the Oracle8i JDBC Developer's Guide and Reference.
The default standard output device in the Oracle8i Java virtual machine (JVM) is the current trace file.
If you want to reroute all standard output from a program executing in the server (output from any
System.out.println() calls, for example) to a user screen, then you can execute the
SET_OUTPUT() procedure of the
DBMS_JAVA package, as follows (inputting the buffer size in bytes):
(Output exceeding the buffer size will be lost.)
If you want your code executing in the server to expressly output to the user screen, you can also use the PL/SQL
DBMS_OUTPUT.PUT_LINE() procedure, instead of the Java
PUT_LINE() procedure is overloaded, accepting either
DATE as input to specify what is printed.
For more information about the
DBMS_OUTPUT package, see the Oracle8i Supplied PL/SQL Packages Reference.
Class loading and name resolution in the server follow a very different paradigm than on a client, because the environments themselves are very different. This section gives only an overview; the topic is discussed in detail in the Oracle8i Java Developer's Guide.
Java name resolution in the Oracle8i JVM includes the following:
CLASSPATHon a client)
A class schema object is said to be resolved when all of its external references to Java names are bound. In general, all the classes of a Java program should be compiled or loaded before they can be resolved. (This is because Java programs are typically written in multiple source files that can reference each other recursively.)
When all the class schema objects of a Java program in the server are resolved and none of them have been modified since being resolved, the program is effectively pre-linked and ready to run.
A class schema object must be resolved before Java objects of the class can be instantiated or methods of the class can be executed.
SQL names (such as names of source, class, and resource schema objects) are not global in the way that Java names are global. The Java Language Specification directs that package names use Internet naming conventions to create globally unique names for Java programs. By contrast, a fully qualified SQL name is interpreted only with respect to the current schema and database. For example, the name
SCOTT.FIZZ in one database does not necessarily denote the same program as
SCOTT.FIZZ in another database. In fact,
SCOTT.FIZZ in one database can even call
SCOTT.FIZZ in another database.
Because of this inherent difference, SQL names must be interpreted and processed differently from Java names. SQL names are relative names and are interpreted from the point of view of the schema where a program is executed. This is central to how the program binds local data stored at that schema. Java names are global names, and the classes that they designate can be loaded at any execution site, with reasonable expectation that those classes will be classes that were used to compile the program.