1
Overview

This chapter provides an overview of the Oracle implementation of JDBC and contains these topics:

What is JDBC?

JDBC (Java Database Connectivity) is a standard Java interface for connecting to relational databases from Java. The JDBC standard was defined by Sun Microsystems, allowing individual providers to implement and extend the standard with their own JDBC drivers.

JDBC is based on the X/Open SQL Call Level Interface, and complies with the SQL92 Entry Level standard.

In addition to the standard JDBC API, Oracle drivers have extensions to properties, types, and performance.

JDBC versus SQLJ

This section has the following subsections:

Developers who are familiar with the Oracle Call Interface (OCI) layer of client-side C code will recognize that JDBC provides the power and flexibility for the Java programmer that OCI does for the C or C++ programmer. Just as with OCI, you can use JDBC to query and update tables where, for example, the number and types of the columns are not known until runtime. This capability is called dynamic SQL. Therefore, JDBC is a way to use dynamic SQL statements in Java programs. Using JDBC, a calling program can construct SQL statements at runtime. Your JDBC program is compiled and run like any other Java program. No analysis or checking of the SQL statements is performed. Any errors that are made in your SQL code raise runtime errors. JDBC is designed as an API for dynamic SQL.

However, many applications do not need to construct SQL statements dynamically because the SQL statements they use are fixed or static. In this case, you can use SQLJ to embed static SQL in Java programs. In static SQL, all of the SQL statements are complete or "textually evident" in the Java program. That is, details of the database object, such as the column names, number of columns in the table, and table name, are known before runtime. SQLJ provides advantages for these applications because it permits error checking at precompile time.

The precompile step of a SQLJ program performs syntax-checking of the embedded SQL, type checking against the database to assure that the data exchanged between Java and SQL have compatible types and proper type conversions, and schema checking to assure congruence between SQL constructs and the database schema. The result of the precompilation is Java source code with SQL runtime code which, in turn, can use JDBC calls. The generated Java code compiles and runs like any other Java program.

Although SQLJ provides direct support for static SQL operations that are known at the time the program is written, it can also inter-operate with dynamic SQL through JDBC. SQLJ allows you to create JDBC objects when they are needed for dynamic SQL operations. In this way, SQLJ and JDBC can co-exist in the same program. Convenient conversions are supported between JDBC connections and SQLJ connection contexts, as well as between JDBC result sets and SQLJ iterators. For more information on this, see the Oracle8i SQLJ Developer's Guide and Reference.

The syntax and semantics of SQLJ and JDBC do not depend on the configuration under which they are running, thus enabling implementation on the client or database side or in the middle tier.

Advantages of SQLJ over JDBC for Static SQL

While JDBC provides a complete dynamic SQL interface from Java to relational databases, SQLJ fills a complementary role for static SQL.

Although you can use static SQL statements in your JDBC programs, they can be represented more conveniently in SQLJ. Some advantages you gain in using SQLJ over JDBC for static SQL statements are:

SQLJ source programs are smaller than equivalent JDBC programs because SQLJ provides a shorter syntax.
SQLJ uses database connections to type-check static SQL code. JDBC, being a completely dynamic API, does not do any type checking until run-time.
SQLJ programs allow direct embedding of Java bind expressions within SQL statements. JDBC requires separate get and/or set call statements for each bind variable and specifies the binding by position number.
SQLJ provides strong typing of query outputs and return parameters and allows type-checking on calls. JDBC passes values to and from SQL without compile-time type checking.
SQLJ provides simplified rules for calling SQL stored procedures and functions.

General Guidelines for using JDBC and SQLJ

Use SQLJ to write your program when:

you want to be able to check your program for errors at translation-time rather than at run-time.
you want to write an application that you can deploy to another database. Using SQLJ, you can customize the static SQL for that database at deployment-time.
you are working with a database that contains compiled SQL. You will want to use SQLJ because you cannot compile SQL statements in a JDBC program.

Use JDBC to write your program when:

your program uses dynamic SQL. For example, you have a program that builds queries on-the-fly or has an interactive component.
you do not want to have a SQLJ layer during deployment or development. For example, you might want to download only the JDBC Thin driver and not the SQLJ runtime libraries to minimize download time over a slow link.

Basic Driver Architecture

This section has the following subsections:

Figure 1-1 illustrates the driver-database architecture for the JDBC Thin, OCI, and Server drivers.

Figure 1-1 Driver-Database Architecture

JDBC Thin Client-Side Driver Architecture

The Oracle JDBC Thin driver is a Type IV driver that is targeted to applet developers. This driver is written in 100% Pure Java and complies with the JDBC 1.22 standard.

For communicating with the database, the driver includes an equivalent implementation of Oracle's TTC presentation protocol and Net8 session protocol in Java. Both of these protocols are lightweight implementation versions of their counterparts on the server. The Net8 protocol runs over TCP/IP only. To use this driver, it is not necessary to install any Oracle-specific software on the client.

The HTTP protocol is stateless but the Thin driver is not. The initial HTTP request to download the applet and the Thin driver is stateless. Once the Thin driver establishes the database connection, the communication between the browser and the database is stateful and in a two-tier configuration.

JDBC OCI Client-Side Driver Architecture

The JDBC OCI driver is a Type II driver that is targeted to client-server Java applications programmers and Java-based middle-tier developers. The JDBC OCI driver converts JDBC invocations to calls to the Oracle Call Interface (OCI). These calls are then sent over Net8 to the Oracle database server.

The JDBC OCI driver is written in a combination of Java and C because it must make calls to the OCI libraries. The driver requires the presence of the OCI libraries, Net8, CORE libraries, and other necessary files on each client machine or middle-tier application server on which it is installed.

JDBC Server Driver Architecture

The JDBC Server driver allows Java programs that use the Oracle 8.1.5 Java Virtual Machine (VM) and run inside the database to communicate with the SQL engine. The Server driver, the Java VM, the database, the KPRB (server-side) C library, and the SQL engine all run within the same address space. There are no network round-trips involved. The programs access the SQL engine by using function calls.

Oracle Extensions to the JDBC Standard

The Oracle JDBC drivers support many of the features described in the JDBC 2.0 standard. This support is provided in the form of Oracle-defined extensions for Oracle datatypes, object types, and their mappings to Java. For more information on these extensions, see Chapter 4, "Oracle Extensions".

Supported JDK and JDBC Versions

Oracle's JDBC drivers, release 8.1.5, support the JDK versions 1.0.2 and 1.1.x. They also comply with JDBC version 1.22 and, in addition, implement most of the features of JDBC version 2.0.

Note:
There are special considerations for using the Thin driver with JDK 1.0.2 and 1.1.1 in the context of applets. See "Working with Applets" for more information on this topic.

JDBC and the Oracle Application Server

Oracle Application Server is a collection of middleware services and tools that provide a scalable, robust, secure, and extensible platform for distributed, object-oriented applications. Oracle Application Server supports access to applications from both Web clients (browsers) using the Hypertext Transfer Protocol (HTTP), and CORBA clients, which use the Common Object Request Broker Architecture (CORBA) and the Internet Inter-ORB Protocol (IIOP).

You can use the JDBC OCI drivers on a middle tier in conjunction with Oracle Web Application Server versions 3.0 and higher. The Oracle Web Application Server bundles JDBC with its distribution. For more information on the use of JDBC and the Oracle Web Application Server, see your Oracle Web Application Server documentation.

JDBC and IDEs

The Oracle JDeveloper Suite provides developers with a single, integrated set of products to build, debug and deploy component-based database applications for the Oracle Internet platform. The Oracle JDeveloper environment contains integrated support for JDBC, including 100% Pure Java and native Oracle8 drivers. The database component of Oracle JDeveloper uses the JDBC drivers to manage the connection between the application running on the client and the server. See your Oracle JDeveloper documentation for more information.

1 Overview