Oracle8i SQLJ Developer's Guide and Reference Release 3 (8.1.7) Part Number A83723-01 |
Library | Service | Contents | Index

## 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 XA transactions (`UserTransaction` in an EJB, or JTS in a CORBA object, for example), then 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 `COMMIT` and `ROLLBACK` operations 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 might 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 "Loaded 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)

  "Alternative Deployment Scenarios" provides a summary of what SQLJ produces. (Note that you would presumably have no declared 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 the `loadjava` utility.

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index