|Oracle8i SQLJ Developer's Guide and Reference
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:
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
sqljimpl examples in that manual use interface implementations that were developed with SQLJ.
If your EJB or CORBA object uses any sort of XA transactions (
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
loadjava is not used).
When you run the SQLJ translator for your EJB program, consider the following:
-ser2classoption so that your profiles are converted to
.serfiles. 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.)
-doption to direct all generated
.serfiles, if any) into a specified directory.
Once you have translated your SQLJ EJB, gather everything into a
.jar file. This includes:
.classfiles for home interface, remote interface, bean implementation, and any dependent classes; any required Java resources
.classfiles, and the profile (either in a
.classfile or a
"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.
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.
.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