SQLJ in the Server

Additional Vehicles for SQLJ in the Server

Most of the discussion throughout this chapter has presumed that SQLJ is being used for stored procedures or stored functions; there has been no special consideration of any other possibilities. Be aware, though, that you can also use SQLJ in the server in the following ways:

in Enterprise JavaBeans
in CORBA server objects

This section introduces the use of Enterprise JavaBeans and CORBA objects. For more information see the Oracle8i Enterprise JavaBeans and CORBA Developer's Guide. The lookup and sqljimpl examples in that manual use interface implementations that were developed with SQLJ.

Note:
If your EJB or CORBA object uses any sort of XA transactions (UserTransaction in an EJB or JTS in a CORBA object, for example), you cannot use explicit SQLJ commit/rollback statements or JDBC commit/rollback methods. Any attempt to do so will result in an exception. You must instead execute your commits and rollbacks through the particular XA interface that you are using.

Enterprise JavaBeans

To use SQLJ in Enterprise JavaBeans (EJBs), develop and translate the SQLJ EJBs on a client and then load all resulting classes and resources into the server. To load and publish EJBs, however, you must use a utility called deployejb (loadjava is not used).

When you run the SQLJ translator for your EJB program, consider the following:

It may be helpful to use the SQLJ -ser2class option so that your profiles are converted to .class files from .ser files. This simplifies the naming of the resulting schema objects in the server, as explained in "Naming of Class and Resource Schema Objects"; however, it prevents you from further customizing the profiles. (To further customize, you must rerun the SQLJ translator and regenerate the profiles.)
It is also helpful to use the SQLJ -d option to direct all generated .class files (and .ser files, if any) into a specified directory.

Once you have translated your SQLJ EJB, gather everything into a .jar file. This includes:

products of EJB development--.class files for home interface, remote interface, bean implementation, and any dependent classes; any required Java resources
products of SQLJ development and translation--application .class files, profile-keys .class file, iterator .class files, and the profile (either in a .class file or a .ser file)

"Summary of Translator Input and Output" provides a summary of what SQLJ produces. (Note that you would presumably have no connection context classes in a program being loaded into the server because the only connection is to the server itself.)

After creating the .jar file, use the deployejb utility to load everything into the server, specifying the .jar file as input.

CORBA Server Objects

You can also use SQLJ for developing CORBA objects that have database DML statements. As with EJBs, you must be careful to include all classes and resource files that the SQLJ translator generates when you load files into the server. For CORBA objects, load and publish as you would for stored procedures.

Create a .jar file to hold all the SQLJ-generated files, as discussed in "Enterprise JavaBeans", and use this file on the command line when you run loadjava.