Release 8.1.5
A64686-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i
Java Stored Procedures Developer's Guide Release 8.1.5 A64686-01 |
|
Stored procedures are Java methods published to SQL and stored in an Oracle database for general use. To publish Java methods, you write call specifications (call specs for short), which map Java method names, parameter types, and return types to their SQL counterparts.
Unlike a wrapper, which adds another layer of execution, a call spec simply publishes the existence of a Java method. So, when you call the method (through its call spec), the run-time system dispatches the call with minimal overhead.
When called by client applications, a stored procedure can accept arguments, reference Java classes, and return Java result values. Figure 1-2 shows a procedure stored in the database and called by various applications.
Except for graphical-user-interface (GUI) methods, any Java method can run in the RDBMS as a stored procedure. The run-time contexts are:
The next three sections describe these contexts.
Functions and procedures are named blocks that encapsulate a sequence of statements. They are like building blocks that you can use to construct modular, maintainable applications.
Generally, you use a procedure to perform an action and a function to compute a value. So, for void Java methods, you use procedure call specs, and for value-returning methods, you use function call specs.
Only top-level and packaged (not local) PL/SQL functions and procedures can be used as call specs. When you define them using the SQL CREATE FUNCTION, CREATE PROCEDURE, and/or CREATE PACKAGE statement, they are stored in the database, where they are available for general use.
Java methods published as functions and procedures must be invoked explicitly. They can accept arguments and are callable from:
Java methods published as functions are also callable from:
A database trigger is a stored procedure associated with a specific table or view. Oracle invokes (fires) the trigger automatically whenever a given DML operation modifies the table or view.
A trigger has three parts: a triggering event (DML operation), an optional trigger constraint, and a trigger action. When the event occurs, the trigger fires and a CALL statement calls a Java method (through its call spec) to perform the action.
Database triggers, which you define using the SQL CREATE TRIGGER statement, let you customize the RDBMS. For example, they can restrict DML operations to regular business hours. Typically, triggers are used to enforce complex business rules, derive column values automatically, prevent invalid transactions, log events transparently, audit transactions, or gather statistics.
A SQL object type is a user-defined composite datatype that encapsulates a set of variables (attributes) with a set of operations (methods), which can be written in Java. The data structure formed by the set of attributes is public (visible to client programs). However, well-behaved programs do not manipulate it directly. Instead, they use the set of methods provided.
When you define an object type using the SQL CREATE ... OBJECT statement, you create an abstract template for some real-world object. The template specifies only those attributes and behaviors the object will need in the application environment. At run time, when you fill the data structure with values, you create an instance of the object type. You can create as many instances (objects) as you need.
Typically, an object type corresponds to some business entity such as a purchase order. To accommodate a variable number of items, object types can use variable-length arrays (varrays) and nested tables. For example, this feature enables a purchase order object type to contain a variable number of line items.
