SQL/MX 3.2.1 Guide to Stored Procedures in Java (H06.26+, J06.15+)

Accessing Application Classes in the External Path
An SPJ method can access by default all application classes within its external path location, which
you specify in the EXTERNAL PATH clause of a CREATE PROCEDURE statement when registering
an SPJ. The external path is either an OSS directory or a JAR file path that contains the SPJ class
file. See Specifying the External Path (page 66) .
If the external path is an OSS directory, only class files in the specified directory (or within packages
in the specified directory) are considered to be in the external path. JAR files within the specified
directory are not considered to be part of the external path.
If the external path is a JAR file path, only class files within the JAR file are considered to be in the
external path. For example, if an SPJ class named myClass is contained in a JAR file named
myJar.jar, the external path is the JAR file path, /usr/myapps/myJar.jar. All classes stored
in the same JAR file as myClass are accessible by default to the SPJ method, myMethod().
Accessing Application Classes Outside the External Path
For an SPJ method to access an application class outside its external path, you must set a search
path in the SPJ environment called the class path. A class path can contain multiple directories and
JAR file paths, which an SPJ class loader uses to search for referenced application classes.
During the execution of a CALL statement, if an SPJ method refers to an application class, an SPJ
class loader first searches the external path for the class and, if the class is not found, it searches
the class path.
For more information, see Setting the Class Path (page 43).
Maintaining Class and JAR Files in an SPJ Environment
You should not modify class and JAR files that are used by SPJs while active SPJ environments exist.
If you update the SPJ classes or referenced application classes on disk, those changes might not
be reflected in currently active SPJ environments, leading to unpredictable and undesirable behavior
of CALL statements.
CAUTION: To prevent unpredictable and undesirable behavior of CALL statements, do not change
SPJ classes or referenced application classes while SPJ environments are active. To update a class
file or a JAR file that contains classes, stop the calling application, which ends the active SQL/MX
UDR server process, install the updated class or JAR file, and then restart the application.
Consider the maintenance implications described next.
Updating the Java Class Files of an SPJ Method
Suppose that you change an SPJ class while an SPJ environment remains active. After you change
the Java class, subsequent calls to the SPJ in the same SPJ environment will cause NonStop SQL/MX
to try to execute the old SPJ method, usually resulting in an error. Although you changed the Java
class file on disk, the old class of the SPJ method remains cached in the JVM of the SPJ environment.
After a class loader loads a class file, it does not reload the same class file unless garbage collection
occurs.
Before installing an updated class file, or a JAR file that contains an updated class file, and before
issuing a CREATE PROCEDURE statement, always stop the calling application, which ends the
active SQL/MX UDR server process. For more information, see Altering an SPJ and Its Java Class
(page 68).
Updating the Java Class Files of a Referenced Application Class
Suppose that two SPJs, each with a different external path location, depend on the same application
class outside the external path but within the class path. Because the SPJ class loaders for each
external path operate independently and do not share information, each loads its own copy of
the application class at different times in the SPJ environment. Each time one of the SPJ class loaders
30 Introduction