805 OCPJP 6 Questions 788 SCJP 5 questions 650 OCPJWCD 5 questions 600 OCAJP 7 questions 610 OCPJP 7 questions 510 Upgrade to OCPJP 7 questions 900 Java J2EE Qns

Tutorials

Upgrade to OCPJP 7 : Describe the JDBC API

SCJP 6/OCPJP Exam Kit

Describe the JDBC API

3.1. Identify the Java statements required to connect to a database using JDBC
Before you process any SQL statement with JDBC, you need to establish a connection with the data source you want to use. A data source can be a DBMS, a legacy file system, or some other source of data with a corresponding JDBC driver.

Typically, a JDBC application connects to a target data source using one of two classes:

  • DriverManager: This fully implemented class connects an application to a data source, which is specified by a database URL. When this class first attempts to establish a connection, it automatically loads any JDBC 4.0 drivers found within the class path. Note that your application must manually load any JDBC drivers prior to version 4.0:

    // manually load JDBC driver class in JVM (before JDBC 4.0)
    try {
        Class.forName("oracle.jdbc.driver.OracleDriver");
    } catch(ClassNotFoundException e) {
        System.err.println("Error loading driver: " + e);
    }
    								

  • DataSource: This interface is preferred over DriverManager because it allows details about the underlying data source to be transparent to your application. A DataSource object's properties are set so that it represents a particular data source.

Specifying Database Connection URLs

A database connection URL is a string that your DBMS JDBC driver uses to connect to a database. It can contain information such as where to search for the database, the name of the database to connect to, and configuration properties. The exact syntax of a database connection URL is specified by your DBMS.

  • Java DB Database Connection URLs

    The following is the database connection URL syntax for Java DB:

    
    jdbc:derby:[subsubprotocol:][databaseName][;attribute=value]*
    
    								

    subsubprotocol specifies where Java DB should search for the database, either in a directory, in memory, in a class path, or in a JAR file. It is typically omitted.

    databaseName is the name of the database to connect to.

    attribute=value represents an optional, semicolon-separated list of attributes. These attributes enable you to instruct Java DB to perform various tasks (create database, encrypt database, etc.)

    The following database connection URL connects the user mikalai to sample database:

    jdbc:derby:sample;user=mikalai;password=secret111
    								

  • MySQL Connector/J Database URL

    The following is the database connection URL syntax for MySQL Connector/J:

    
    jdbc:mysql://[host][,failoverhost...][:port]/[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
    
    								

    host:port is the host name and port number of the computer hosting your database. If not specified, the default values of host and port are 127.0.0.1 and 3306, respectively.

    database is the name of the database to connect to. If not specified, a connection is made with no default database.

    failoverhost is the name of a standby database server (MySQL Connector/J supports failover).

    propertyName=propertyValue represents an optional, ampersand-separated list of properties. These attributes enable you to instruct MySQL Connector/J to perform various tasks.

Using the DriverManager Class

Connecting to your DBMS with the DriverManager class involves calling the method DriverManager.getConnection(...). The following method establishes a database connection:

public Connection getConnection() throws SQLException {
    Connection conn = null;

    Properties connectionProps = new Properties();
    connectionProps.put("user", userName);
    connectionProps.put("password", password);

    if (dbms.equals("mysql")) {
        conn = DriverManager.getConnection("jdbc:mysql://" + serverName + ":" + portNumber + "/" + dbName, connectionProps);
    } else if (dbms.equals("derby")) {
        conn = DriverManager.getConnection("jdbc:derby:" + dbName + ";create=true", connectionProps);
    }
    return conn;
}
					

The method DriverManager.getConnection(...) establishes a database connection. This method requires a database URL, which varies depending on your DBMS. The following are some examples of database URLs:

  • MySQL: jdbc:mysql://localhost:3306/testdb, where localhost is the name of the server hosting your database, 3306 is the port number, and testdb is the name of the database.

  • Java DB: jdbc:derby:testdb;create=true, where testdb is the name of the database to connect to, and create=true instructs the DBMS to create the database.

    NOTE: This URL establishes a database connection with the Java DB Embedded Driver. Java DB also includes a Network Client Driver, which uses a different URL syntax.

This method specifies the user name and password required to access the DBMS with a Properties object.

NOTE: In previous versions of JDBC, to obtain a connection, you first had to initialize your JDBC driver by calling the method Class.forName(...). This method required an object of type java.sql.Driver. Each JDBC driver contains one or more classes that implements the interface java.sql.Driver. See the documentation of your DBMS driver to obtain the name of the class that implements the interface java.sql.Driver. Any JDBC 4.0 drivers that are found in your class path are AUTOMATICALLY loaded. However, you must MANUALLY load any drivers prior to JDBC 4.0 with the method Class.forName(...).

The method above returns a java.sql.Connection object, which represents a connection with the DBMS or a specific database. Query the database through this object.



Use the JDBC 4.1 RowSetProvider, RowSetFactory, and new RowSet interfaces

The javax.sql.RowSet is the interface that adds support to the JDBC API for the JavaBeans component model. A rowset, which can be used as a JavaBeans component in a visual Bean development environment, can be created and configured at design time and executed at run time.

The RowSet interface provides a set of JavaBeans properties that allow a RowSet instance to be configured to connect to a JDBC data source and read some data from the data source. A group of setter methods (setInt(...), setBytes(...), setString(...), and so on) provide a way to pass input parameters to a rowset's command property. This command is the SQL query the rowset uses when it gets its data from a relational database, which is generally the case.

The RowSet interface supports JavaBeans events, allowing other components in an application to be notified when an event occurs on a rowset, such as a change in its value.

The RowSet interface is unique in that it is intended to be implemented using the rest of the JDBC API. In other words, a RowSet implementation is a layer of software that executes "on top" of a JDBC driver. Implementations of the RowSet interface can be provided by anyone, including JDBC driver vendors who want to provide a RowSet implementation as part of their JDBC products.

A RowSet object may make a connection with a data source and maintain that connection throughout its life cycle, in which case it is called a connected rowset. A rowset may also make a connection with a data source, get data from it, and then close the connection. Such a rowset is called a disconnected rowset. A disconnected rowset may make changes to its data while it is disconnected and then send the changes back to the original source of the data, but it must reestablish a connection to do so.

A disconnected rowset may have a reader (a RowSetReader object) and a writer (a RowSetWriter object) associated with it. The reader may be implemented in many different ways to populate a rowset with data, including getting data from a non-relational data source. The writer can also be implemented in many different ways to propagate changes made to the rowset's data back to the underlying data source.

Rowsets are easy to use. The RowSet interface extends the standard java.sql.ResultSet interface. The RowSetMetaData interface extends the java.sql.ResultSetMetaData interface.

The java.sql.ResultSet interface requires a persistent connection with a database to invoke the INSERT, UPDATE, and DELETE row operations on the database table data. The RowSet interface extends the ResultSet interface and is a container for tabular data that may operate without being connected to the data source. Thus, the RowSet interface reduces the overhead of a persistent connection with the database.

In Java 5 SE, five new implementations of RowSetJdbcRowSet, CachedRowSet, WebRowSet, FilteredRowSet, and JoinRowSet — were introduced. The WebRowSet interface extends the RowSet interface and is the XML document representation of a RowSet object. A WebRowSet object represents a set of fetched database table rows, which may be modified without being connected to the database.

You can use an instance of RowSetFactory to create a RowSet object. The following example uses an instance of RowSetFactory to create the JdbcRowSet object, jdbcRs:

public void testJdbcRowSet(String username, String password) throws SQLException {

    RowSetFactory myRowSetFactory = null;
    JdbcRowSet jdbcRs = null;
    ResultSet rs = null;
    Statement stmt = null;

    try {

        myRowSetFactory = RowSetProvider.newFactory();
        jdbcRs = myRowSetFactory.createJdbcRowSet();

        jdbcRs.setUrl("jdbc:myDriver:myAttribute");
        jdbcRs.setUsername(username);
        jdbcRs.setPassword(password);

        jdbcRs.setCommand("SELECT COF_NAME, SUP_ID, PRICE, SALES, TOTAL FROM COFFEES");
        jdbcRs.execute();

        // ...
					

The following statement creates the RowSetProvider object myRowSetFactory with the default RowSetFactory implementation, com.sun.rowset.RowSetFactoryImpl:

RowSetFactory myRowSetFactory = RowSetProvider.newFactory();
CachedRowSet crs = myRowSetFactory.createCachedRowSet()
					

Alternatively, if your JDBC driver has its own RowSetFactory implementation, you can specify it as an argument of newFactory(...) method:

RowSetFactory rsf = RowSetProvider.newFactory("com.sun.rowset.RowSetFactoryImpl", null);
WebRowSet wrs = rsf.createWebRowSet();
					

The following statements create the JdbcRowSet object jdbcRs and configure its database connection properties:

jdbcRs = myRowSetFactory.createJdbcRowSet();

jdbcRs.setUrl("jdbc:myDriver:myAttribute");
jdbcRs.setUsername(username);
jdbcRs.setPassword(password);
					

The RowSetFactory interface contains methods to create the different types of RowSet implementations available in JDBC 4.1 and later:

package javax.sql.rowset;

public interface RowSetFactory {

    CachedRowSet createCachedRowSet();     // Creates a new instance of a CachedRowSet

    FilteredRowSet createFilteredRowSet(); // Creates a new instance of a FilteredRowSet

    JdbcRowSet createJdbcRowSet();         // Creates a new instance of a JdbcRowSet

    JoinRowSet createJoinRowSet();         // Creates a new instance of a JoinRowSet

    WebRowSet createWebRowSet();           // Creates a new instance of a WebRowSet
}
					

  • javax.sql.rowset.JdbcRowSet interface.

    A wrapper around a ResultSet object that makes it possible to use the result set as a JavaBeans component. Thus, a JdbcRowSet object can be one of the Beans that a tool makes available for composing an application. Because a JdbcRowSet is a connected rowset, that is, it continually maintains its connection to a database using a JDBC technology-enabled driver, it also effectively makes the driver a JavaBeans component.

    Because it is always connected to its database, an instance of JdbcRowSet can simply take calls invoked on it and in turn call them on its ResultSet object. As a consequence, a result set can, for example, be a component in a Swing application.

    Another advantage of a JdbcRowSet object is that it can be used to make a ResultSet object scrollable and updatable. All RowSet objects are by default scrollable and updatable. If the driver and database being used do not support scrolling and/or updating of result sets, an application can populate a JdbcRowSet object with the data of a ResultSet object and then operate on the JdbcRowSet object as if it were the ResultSet object.

  • javax.sql.rowset.CachedRowSet interface.

    A CachedRowSet object is a container for rows of data that caches its rows in memory, which makes it possible to operate without always being connected to its data source. Further, it is a JavaBeans component and is scrollable, updatable, and serializable. A CachedRowSet object typically contains rows from a result set, but it can also contain rows from any file with a tabular format, such as a spread sheet. The reference implementation supports getting data only from a ResultSet object, but developers can extend the SyncProvider implementations to provide access to other tabular data sources.

    An application can modify the data in a CachedRowSet object, and those modifications can then be propagated back to the source of the data:

    public interface CachedRowSet extends RowSet, Joinable {
        ...
        void acceptChanges(); // Propagates row update, insert and delete changes made
                              // to this CachedRowSet object to the underlying data source.
    
        void acceptChanges(Connection con); // Propagates all row update, insert and delete
                                            // changes to the data source backing this CachedRowSet object using the
                                            // specified Connection object to establish a connection to the data source.
        ...
    }
    								

    A CachedRowSet object is a disconnected rowset, which means that it makes use of a connection to its data source only briefly. It connects to its data source while it is reading data to populate itself with rows and again while it is propagating changes back to its underlying data source. The rest of the time, a CachedRowSet object is disconnected, including while its data is being modified. Being disconnected makes a RowSet object much leaner and therefore much easier to pass to another component. For example, a disconnected RowSet object can be serialized and passed over the wire to a thin client such as a personal digital assistant (PDA).

  • javax.sql.rowset.WebRowSet interface.

    The WebRowSetImpl provides the standard reference implementation, which may be extended if required.

    The standard WebRowSet XML Schema definition describes the standard XML document format required when describing a RowSet object in XML and must be used be all standard implementations of the WebRowSet interface to ensure interoperability. In addition, the WebRowSet schema uses specific SQL/XML Schema annotations, thus ensuring greater cross platform inter-operability.

  • javax.sql.rowset.JoinRowSet interface.

    The JoinRowSet interface provides a mechanism for combining related data from different RowSet objects into one JoinRowSet object, which represents an SQL JOIN. In other words, a JoinRowSet object acts as a container for the data from RowSet objects that form an SQL JOIN relationship.

    The Joinable interface provides the methods for setting, retrieving, and unsetting a match column, the basis for establishing an SQL JOIN relationship. The match column may alternatively be set by supplying it to the appropriate version of the JointRowSet method addRowSet.

    public interface JoinRowSet extends WebRowSet {
        ...
        void addRowSet(Joinable rowset); // Adds the given RowSet object to this JoinRowSet object.
    
        void addRowSet(RowSet[] rowset, int[] columnIdx); // Adds one or more RowSet objects contained
                                                          // in the given array of RowSet objects to this
                                                          // JoinRowSet object and sets the match column for each of the RowSet objects to the match columns in the given array of column indexes.
    
        void addRowSet(RowSet[] rowset, String[] columnName); // Adds one or more RowSet objects contained
                                                              // in the given array of RowSet objects to this
                                                              // JoinRowSet object and sets the match column for
                                                              // each of the RowSet objects to the match columns
                                                              in the given array of column names.
    
        void addRowSet(RowSet rowset, int columnIdx); // Adds the given RowSet object to this JoinRowSet object and
                                                      // sets the designated column as the match column for the RowSet
                                                      // object.
    
        void addRowSet(RowSet rowset, String columnName); // Adds rowset to this JoinRowSet object and sets the
                                                          // designated column as the match column.
        ...
    }
    								

    The type of JOIN to be established is determined by setting one of the JoinRowSet constants using the method setJoinType. The following SQL JOIN types can be set:

    • CROSS_JOIN

    • FULL_JOIN

    • INNER_JOIN - the default if no JOIN type has been set

    • LEFT_OUTER_JOIN

    • RIGHT_OUTER_JOIN

    Note that if no type is set, the JOIN will automatically be an inner join.

  • javax.sql.rowset.FilteredRowSet interface.

    There are occasions when a RowSet object has a need to provide a degree of filtering to its contents. One possible solution is to provide a query language for all standard RowSet implementations; however, this is an impractical approach for lightweight components such as disconnected RowSet objects. The FilteredRowSet interface seeks to address this need without supplying a heavyweight query language along with the processing that such a query language would require.

    A JDBC FilteredRowSet standard implementation implements the RowSet interfaces and extends the CachedRowSet class. The CachedRowSet class provides a set of protected cursor manipulation methods, which a FilteredRowSet implementation can override to supply filtering support.

    By implementing a javax.sql.rowset.Predicate interface (see the Range class below), a FilteredRowSet could then be used as described below:

    public class Range implements Predicate {
        public boolean evaluate(RowSet rs) {
            ...
        }
        ...
    }
    								

    FilteredRowSet frs = new FilteredRowSetImpl();
    frs.populate(rs);
    
    Range name = new Range("Alpha", "Bravo", "columnName");
    frs.setFilter(name);
    
    frs.next() // only names from "Alpha" to "Bravo" will be returned
    								

    In the example above, we initialize a Range object which implements the javax.sql.rowset.Predicate interface. This object expresses the following constraints: All rows outputted or modified from this FilteredRowSet object must fall between the values 'Alpha' and 'Bravo' both values inclusive, in the column 'columnName'. If a filter is applied to a FilteredRowSet object that contains no data that falls within the range of the filter, no rows are returned.

    This framework allows multiple classes implementing predicates to be used in combination to achieved the required filtering result with out the need for query language processing.



Use JDBC transactions

A transaction is a logical unit of work.

Transactional support allows applications to ensure the following:

  • All the steps to complete a logical unit of work are followed.

  • When one of the steps to the unit of work files fails, all the work done as part of that logical unit of work can be undone and the database can return to its previous state before the transaction began.

Transactions are used to provide data integrity, correct application semantics, and a consistent view of data during concurrent access. All Java Database Connectivity (JDBC) compliant drivers must support transactions.

All transactional work is handled at the Connection object level. When the work for a transaction completes, it can be finalized by calling the commit() method. If the application aborts the transaction, the rollback() method is called.

All Statement objects under a Connection are a part of the transaction. This means is that if an application creates three Statement objects and uses each object to make changes to the database, when a commit or rollback call happens, the work for all three statements either becomes permanent or is discarded.

JDBC auto-commit mode

By default, JDBC uses an operation mode called auto-commit. This means that every update to the database is immediately made permanent.

Any situation where a logical unit of work requires more than one update to the database cannot be done safely in auto-commit mode. If something happens to the application or the system after one update is made and before any other updates are made, the first change cannot be undone when running in auto-commit mode.

Because changes are instantly made permanent in auto-commit mode, there is no need for the application to call the commit() method or the rollback() method. This makes applications easier to write.

Auto-commit mode can be enabled and disabled dynamically during a connection's existence. Auto-commit can be disabled in the following way, assuming that data source already exists:

Connection conn = dataSource.getConnection();
conn.setAutoCommit(false);  // Disables auto-commit
					

NOTE: If the auto-commit setting is changed in the middle of a transaction, any pending work is automatically committed. If setAutoCommit(...) is called and the auto-commit mode is not changed, the call is a no-op.

NOTE: there is NO Connection.begin() method to begin a transaction!

The first call of Connection.setAutoCommit(false) and each call of Connection.commit() implicitly mark the start of a transaction. Transactions can be undone before they are committed by calling Connection.rollback().



Use the proper JDBC API to submit queries and read results from the database

Creating Statements

A java.sql.Statement is an interface that represents a SQL statement. You execute Statement objects, and they generate ResultSet objects, which is a table of data representing a database result set. You need a java.sql.Connection object to create a Statement object.

For example, you can create Statement object with the following code:

Statement stmt = con.createStatement();
					

There are three different kinds of statements:

  1. Statement: Used to implement simple static SQL statements with NO parameters.

  2. PreparedStatement (extends Statement): Used for precompiling SQL statements that might contain input parameters.

  3. CallableStatement (extends PreparedStatement): Used to execute stored procedures that may contain both input and output parameters.

Executing Queries

To execute a query, call an execute(...) method from Statement such as the following:

  • boolean execute(String sql) throws SQLException: Returns true if the first object that the query returns is a ResultSet object. Use this method if the query could return one or more ResultSet objects. Retrieve the ResultSet objects returned from the query by repeatedly calling Statement.getResutSet.

  • ResultSet executeQuery(String sql) throws SQLException: Executes the given SQL statement, which returns a single ResultSet object.

     ResultSet rs = stmt.executeQuery("SELECT * FROM PERSON");
    								

    Note:This method CANNOT be called on a PreparedStatement or CallableStatement.

  • int executeUpdate(String sql) throws SQLException: Executes the given SQL statement, which may be an INSERT, UPDATE, or DELETE statement or an SQL statement that returns nothing, such as an SQL DDL statement.

    Note:This method CANNOT be called on a PreparedStatement or CallableStatement.

Processing ResultSet Objects

You access the data in a ResultSet object through a cursor. Note that this cursor is not a database cursor. This cursor is a pointer that points to one row of data in the ResultSet object. Initially, the cursor is positioned before the first row. You call various methods defined in the ResultSet object to move the cursor.

For example, you can repeatedly call the method ResultSet.next() to move the cursor forward by one row. Every time you call next(), the method outputs the data in the row where the cursor is currently positioned.

The ResultSet interface provides getter methods (getBoolean, getLong, and so on) for retrieving column values from the current row. Values can be retrieved using either the index number of the column or the name of the column. NOTE: column names used as input to getter methods are case insensitive.

In general, using the column index will be more efficient. Columns are numbered from 1. For maximum portability, result set columns within each row should be read in left-to-right order, and each column should be read only once.

while (resultSet.next()) {
    int id = resultSet.getInt("ID");
    String name = resultSet.getString("NAME");
    System.out.println("ID: " + id);
    System.out.println("NAME: " + name);
    System.out.println();
}
					

You can also get data from ResultSet by column index (NOTE: first column has index 1, not 0):

while (resultSet.next()) {
    int id = resultSet.getInt(1);
    String name = resultSet.getString(2);
    System.out.println("ID: " + id);
    System.out.println("NAME: " + name);
    System.out.println();
}
					



Use JDBC PreparedStatement and CallableStatement

Overview of Prepared Statements

Sometimes it is more convenient to use a PreparedStatement object for sending SQL statements to the database. This special type of statement is derived from the more general class, Statement.

Although PreparedStatement objects can be used for SQL statements with no parameters, you probably use them most often for SQL statements that take parameters. The advantage of using SQL statements that take parameters is that you can use the same statement and supply it with different values each time you execute it.

The following creates a PreparedStatement object that takes two input parameters:

PreparedStatement statement = connect.prepareStatement("UPDATE PERSON SET NAME = ? WHERE ID = ?");
					

You must supply values in place of the question mark placeholders (if there are any) before you can execute a PreparedStatement object. Do this by calling one of the setter methods defined in the PreparedStatement class. The following statements supply the two question mark placeholders in the PreparedStatement named statement:

statement.setString(1, "Mikola Zaikin");
statement.setInt(2, 1);
					

The first argument for each of these setter methods specifies the question mark placeholder. In this example, setString(...) specifies the first placeholder and setInt(...) specifies the second placeholder.

After a parameter has been set with a value, it retains that value until it is reset to another value, or the method clearParameters() is called. Using the PreparedStatement object statement, the following code fragment illustrates reusing a prepared statement after resetting the value of one of its parameters and leaving the other one the same:

statement.setString(1, "Mikola Zaikin");
statement.setInt(2, 1);
statement.executeUpdate();

statement.setString(1, "Mikalai Zaikin");
statement.executeUpdate();
					

PreparedStatement method summary:

  • void addBatch() throws SQLException: Adds a set of parameters to this PreparedStatement object's batch of commands.

  • void clearParameters() throws SQLException: Clears the current parameter values immediately.

    In general, parameter values remain in force for repeated use of a statement. Setting a parameter value automatically clears its previous value. However, in some cases it is useful to immediately release the resources used by the current parameter values; this can be done by calling the method clearParameters().

  • boolean execute() throws SQLException: Executes the SQL statement in this PreparedStatement object, which may be any kind of SQL statement. Some prepared statements return multiple results; the execute() method handles these complex statements as well as the simpler form of statements handled by the methods executeQuery() and executeUpdate().

    The execute() method returns a boolean to indicate the form of the first result. You must call either the method getResultSet() or getUpdateCount() to retrieve the result; you must call getMoreResults to move to any subsequent result(s).

  • ResultSet executeQuery() throws SQLException: Executes the SQL query in this PreparedStatement object and returns the ResultSet object generated by the query.

  • int executeUpdate() throws SQLException: Executes the SQL statement in this PreparedStatement object, which must be an SQL Data Manipulation Language (DML) statement, such as INSERT, UPDATE or DELETE; or an SQL statement that returns nothing, such as a DDL statement.

You can often make coding easier by using a for loop or a while loop to set values for input parameters:

connection.setAutoCommit(false);
PreparedStatement preparedStatement = connection.prepareStatement(sql);
...
for (...) {
    preparedStatement.clearParameters();
    preparedStatement.setObject(1, someValue);
    preparedStatement.execute();
}
connection.commit();
...
preparedStatement.close(); // Do this in the finally block or use try-with-resource!
					

or more efficient:

connection.setAutoCommit(false);
PreparedStatement preparedStatement = connection.prepareStatement(sql);
...
for (...) {
    preparedStatement.setObject(1, someValue);
    preparedStatement.addBatch();
}
preparedStatement.execute();
connection.commit();
...
preparedStatement.close(); // Do this in the finally block or use try-with-resource!
					

CallableStatement Overview

A CallableStatement object provides a way to call stored procedures in a standard way for all RDBMSs. A stored procedure is stored in a database; the call to the stored procedure is what a CallableStatement object contains. This call is written in an escape syntax that may take one of two forms: one form with a result parameter, and the other without one. A result parameter, a kind of OUT parameter, is the return value for the stored procedure. Both forms may have a variable number of parameters used for input (IN parameters), output (OUT parameters), or both (INOUT parameters). A question mark serves as a placeholder for a parameter.

The syntax for invoking a stored procedure using the JDBC API is shown here. Note that the square brackets indicate that what is between them is optional; they are not themselves part of the syntax.

{call procedure_name[(?, ?, ...)]}
					

The syntax for a procedure that returns a result parameter is:

{? = call procedure_name[(?, ?, ...)]}
					

The syntax for a stored procedure with no parameters would look like this:

{call procedure_name}
					

CallableStatement inherits Statement methods, which deal with SQL statements in general, and it also inherits PreparedStatement methods, which deal with IN parameters. All of the methods defined in CallableStatement deal with OUT parameters or the output aspect of INOUT parameters: registering the JDBC types of the OUT parameters, retrieving values from them, or checking whether a returned value was JDBC NULL. Whereas the getXXX methods defined in ResultSet retrieve values from a result set, the getXXX methods in CallableStatement retrieve values from the OUT parameters and/or return value of a stored procedure.


  Upgrade to OCPJP 7 Java SE 7 Programmer (1Z0-805) Guide

  • Language Enhancements
  • Design Patterns
  • Describe the JDBC API
  • Concurrency
  • Localization
  • Java File I/O (NIO.2)


  • Mock Questions

      scwcd 1.5 mock questions

  • Servlet Basic
  • The Structure and Deployment of Web Applications
  • The Web Container Model
  • Servlet event listeners
  • Session Management,session listeners
  • Servlet Filter
  • Web Application Security
  • j2ee patterns
  • JSP Directives
  • JSP page life cycle
  • JSP implicit objects
  • JSP include
  • Expression Language (EL)
  • JSTL
  • Building a Custom Tag Library
  • scjp 1.5 | scjp 1.6 | scwcd 1.5
    Java Certifications
    www.javacertifications.net