java.sql Package ContainsDriverManager facilityjava.sql and javax.sql Features Introduced in the JDBC 4.2 APIjava.sql and javax.sql Features Introduced in the JDBC 4.1 APIjava.sql and javax.sql Features Introduced in the JDBC 4.0 APIjava.sql and javax.sql Features Introduced in the JDBC 3.0 APIjava.sql Features Introduced in the JDBC 2.1 Core APIjavax.sql Features Introduced in the JDBC 2.0 Optional Package APIDataSource Object to Make a Connectionjavax.sql.RowSet group of interfaces, can be customized to use and update data from a spread sheet, flat file, or any other tabular data source.
java.sql package, referred to as the JDBC core API, and the javax.sql package, referred to as the JDBC Optional Package API. This complete JDBC API is included in the JavaTM Standard Edition (Java SETM), version 7. The javax.sql package extends the functionality of the JDBC API from a client-side API to a server-side API, and it is an essential part of the JavaTM Enterprise Edition (Java EETM) technology.
Classes, interfaces, methods, fields, constructors, and exceptions have the following "since" tags that indicate when they were introduced into the Java platform. When these "since" tags are used in JavadocTM comments for the JDBC API, they indicate the following:
NOTE: Many of the new features are optional; consequently, there is some variation in drivers and the features they support. Always check your driver‘s documentation to see whether it supports a feature before you try to use it.
NOTE: The class SQLPermission was added in the JavaTM 2 SDK, Standard Edition, version 1.3 release. This class is used to prevent unauthorized access to the logging stream associated with the DriverManager, which may contain information such as table names, column data, and so on.
java.sql Package Containsjava.sql package contains API for the following:
DriverManager facility
DriverManager class -- makes a connection with a driverSQLPermission class -- provides permission when code running within a Security Manager, such as an applet, attempts to set up a logging stream through the DriverManagerDriver interface -- provides the API for registering and connecting drivers based on JDBC technology ("JDBC drivers"); generally used only by the DriverManager classDriverPropertyInfo class -- provides properties for a JDBC driver; not used by the general userStatement -- used to send basic SQL statementsPreparedStatement -- used to send prepared statements or basic SQL statements (derived from Statement)CallableStatement -- used to call database stored procedures (derived from PreparedStatement)Connection interface -- provides methods for creating statements and managing connections and their propertiesSavepoint -- provides savepoints in a transactionResultSet interfaceArray interface -- mapping for SQL ARRAYBlob interface -- mapping for SQL BLOBClob interface -- mapping for SQL CLOBDate class -- mapping for SQL DATENClob interface -- mapping for SQL NCLOBRef interface -- mapping for SQL REFRowId interface -- mapping for SQL ROWIDStruct interface -- mapping for SQL STRUCTSQLXML interface -- mapping for SQL XMLTime class -- mapping for SQL TIMETimestamp class -- mapping for SQL TIMESTAMPTypes class -- provides constants for SQL typesSQLData interface -- specifies the mapping of a UDT to an instance of this classSQLInput interface -- provides methods for reading UDT attributes from a streamSQLOutput interface -- provides methods for writing UDT attributes back to a streamDatabaseMetaData interface -- provides information about the databaseResultSetMetaData interface -- provides information about the columns of a ResultSet objectParameterMetaData interface -- provides information about the parameters to PreparedStatement commandsSQLException -- thrown by most methods when there is a problem accessing data and by some methods for other reasonsSQLWarning -- thrown to indicate a warningDataTruncation -- thrown to indicate that data may have been truncatedBatchUpdateException -- thrown to indicate that not all commands in a batch update executed successfully
java.sql and javax.sql Features Introduced in the JDBC 4.2 APIJDBCType enum and SQLType interfaceREF CURSORS in CallableStatementDatabaseMetaData methods to return maximum Logical LOB size and if Ref Cursors are supported
java.sql and javax.sql Features Introduced in the JDBC 4.1 APIConnection, ResultSet and Statement objects to be used with the try-with-resources statementCallableStatement and ResultSet to specify the Java type to convert to via the getObject methodDatabaseMetaData methods to return PseudoColumns and if a generated key is always returnedConnection to specify a database schema, abort and timeout a physical connection.Statement object when its dependent objects have been closedDriver, DataSource, ConnectionPoolDataSource and XADataSourcejava.sql and javax.sql Features Introduced in the JDBC 4.0 APIjava.sql.Driver class via Class.forNamePreparedStatement that is associated with a PooledConnection has been closed or the driver determines is invalid
java.sql and javax.sql Features Introduced in the JDBC 3.0 APIConnectionPoolDataSource -- specify how connections are to be pooledPreparedStatement objectResultSet objects returned from CallableStatement objects open at the same timeCallableStatement objects by name as well as by indexResultSet holdability -- ability to specify whether cursors should be held open or closed at the end of a transactionRef object referencesBLOB, CLOB, ARRAY, and REF values.java.sql.Types.DATALINK data type -- allows JDBC drivers access to objects stored outside a data source
java.sql Features Introduced in the JDBC 2.1 Core APIResultSet interface that allow the cursor to be moved to a particular row or to a position relative to its current positionResultSet updater methodsjava.math.BigDecimal values, additional security, and support for time zones in date, time, and timestamp values.
javax.sql Features Introduced in the JDBC 2.0 Optional Package APIDataSource interface as a means of making a connection. The Java Naming and Directory InterfaceTM (JNDI) is used for registering a DataSource object with a naming service and also for retrieving it.RowSet technology -- providing a convenient means of handling and passing data
DISTINCT type are the UDTs that may be custom mapped. The following three steps set up a custom mapping:DISTINCT type in SQLSQLData interface.Connection object‘s type map that contains two things:
Class object for the class that implements the SQLData interfaceWhen these are in place for a UDT, calling the methods ResultSet.getObject or CallableStatement.getObject on that UDT will automatically retrieve the custom mapping for it. Also, thePreparedStatement.setObject method will automatically map the object back to its SQL type to store it in the data source.
java.sql package and, as of the version 1.4 release, is included in the Java Platform, Standard Edition (Java SETM). It remains an essential part of the Java Platform, Enterprise Edition (Java EETM).
The javax.sql package provides for the following:
DataSource interface as an alternative to the DriverManager for establishing a connection with a data sourceApplications use the DataSource and RowSet APIs directly, but the connection pooling and distributed transaction APIs are used internally by the middle-tier infrastructure.
DataSource Object to Make a Connectionjavax.sql package provides the preferred way to make a connection with a data source. The DriverManager class, the original mechanism, is still valid, and code using it will continue to run. However, the newer DataSource mechanism is preferred because it offers many advantages over the DriverManager mechanism.
These are the main advantages of using a DataSource object to make a connection:
DataSource object that is implemented to work with the middle-tier infrastructure. Connections made through the DriverManager do not have connection and statement pooling or distributed transaction capabilities.Driver vendors provide DataSource implementations. A particular DataSource object represents a particular physical data source, and each connection the DataSource object creates is a connection to that physical data source.
A logical name for the data source is registered with a naming service that uses the Java Naming and Directory InterfaceTM (JNDI) API, usually by a system administrator or someone performing the duties of a system administrator. An application can retrieve the DataSource object it wants by doing a lookup on the logical name that has been registered for it. The application can then use the DataSource object to create a connection to the physical data source it represents.
A DataSource object can be implemented to work with the middle tier infrastructure so that the connections it produces will be pooled for reuse. An application that uses such a DataSourceimplementation will automatically get a connection that participates in connection pooling. A DataSource object can also be implemented to work with the middle tier infrastructure so that the connections it produces can be used for distributed transactions without any special coding.
DataSource object that is implemented to work with a middle tier connection pool manager will participate in connection pooling. This can improve performance dramatically because creating new connections is very expensive. Connection pooling allows a connection to be used and reused, thus cutting down substantially on the number of new connections that need to be created.
Connection pooling is totally transparent. It is done automatically in the middle tier of a Java EE configuration, so from an application‘s viewpoint, no change in code is required. An application simply uses the DataSource.getConnection method to get the pooled connection and uses it the same way it uses any Connection object.
The classes and interfaces used for connection pooling are:
ConnectionPoolDataSourcePooledConnectionConnectionEventConnectionEventListenerStatementEventStatementEventListenerConnectionPoolDataSource object is called on to create a PooledConnection object, the connection pool manager will register as a ConnectionEventListener object with the new PooledConnection object. When the connection is closed or there is an error, the connection pool manager (being a listener) gets a notification that includes a ConnectionEvent object.
If the connection pool manager supports Statement pooling, for PreparedStatements, which can be determined by invoking the method DatabaseMetaData.supportsStatementPooling, the connection pool manager will register as a StatementEventListener object with the new PooledConnection object. When the PreparedStatement is closed or there is an error, the connection pool manager (being a listener) gets a notification that includes a StatementEvent object.
DataSource object that is implemented to work with the middle tier infrastructure may participate in distributed transactions. This gives an application the ability to involve data sources on multiple servers in a single transaction.
The classes and interfaces used for distributed transactions are:
XADataSourceXAConnectionThe XAConnection interface is derived from the PooledConnection interface, so what applies to a pooled connection also applies to a connection that is part of a distributed transaction. A transaction manager in the middle tier handles everything transparently. The only change in application code is that an application cannot do anything that would interfere with the transaction manager‘s handling of the transaction. Specifically, an application cannot call the methods Connection.commit or Connection.rollback, and it cannot set the connection to be in auto-commit mode (that is, it cannot call Connection.setAutoCommit(true)).
An application does not need to do anything special to participate in a distributed transaction. It simply creates connections to the data sources it wants to use via theDataSource.getConnection method, just as it normally does. The transaction manager manages the transaction behind the scenes. The XADataSource interface creates XAConnectionobjects, and each XAConnection object creates an XAResource object that the transaction manager uses to manage the connection.
RowSet interface works with various other classes and interfaces behind the scenes. These can be grouped into three categories.RowSetListenerRowSet object is a JavaBeansTM component because it has properties and participates in the JavaBeans event notification mechanism. The RowSetListener interface is implemented by a component that wants to be notified about events that occur to a particular RowSet object. Such a component registers itself as a listener with a rowset via theRowSet.addRowSetListener method.
When the RowSet object changes one of its rows, changes all of it rows, or moves its cursor, it also notifies each listener that is registered with it. The listener reacts by carrying out its implementation of the notification method called on it.
RowSetEventRowSet object creates an instance of RowSetEvent and passes it to the listener. The listener can use this RowSetEvent object to find out which rowset had the event.
RowSetMetaDataResultSetMetaData interface, provides information about the columns in a RowSet object. An application can use RowSetMetaData methods to find out how many columns the rowset contains and what kind of data each column can contain.
The RowSetMetaData interface provides methods for setting the information about columns, but an application would not normally use these methods. When an application calls the RowSet method execute, the RowSet object will contain a new set of rows, and its RowSetMetaData object will have been internally updated to contain information about the new columns.
RowSet object that implements the RowSetInternal interface can call on the RowSetReader object associated with it to populate itself with data. It can also call on the RowSetWriterobject associated with it to write any changes to its rows back to the data source from which it originally got the rows. A rowset that remains connected to its data source does not need to use a reader and writer because it can simply operate on the data source directly.
RowSetInternalRowSetInternal interface, a RowSet object gets access to its internal state and is able to call on its reader and writer. A rowset keeps track of the values in its current rows and of the values that immediately preceded the current ones, referred to as the original values. A rowset also keeps track of (1) the parameters that have been set for its command and (2) the connection that was passed to it, if any. A rowset uses the RowSetInternal methods behind the scenes to get access to this information. An application does not normally invoke these methods directly.
RowSetReaderRowSet object that has implemented the RowSetInternal interface can call on its reader (the RowSetReader object associated with it) to populate it with data. When an application calls the RowSet.execute method, that method calls on the rowset‘s reader to do much of the work. Implementations can vary widely, but generally a reader makes a connection to the data source, reads data from the data source and populates the rowset with it, and closes the connection. A reader may also update theRowSetMetaData object for its rowset. The rowset‘s internal state is also updated, either by the reader or directly by the method RowSet.execute.RowSetWriterRowSet object that has implemented the RowSetInternal interface can call on its writer (the RowSetWriter object associated with it) to write changes back to the underlying data source. Implementations may vary widely, but generally, a writer will do the following:
The RowSet interface may be implemented in any number of ways, and anyone may write an implementation. Developers are encouraged to use their imaginations in coming up with new ways to use rowsets.
IMPORTANT NOTE: Code that uses API marked "Since 1.6" must be run using a JDBC technology driver that implements the JDBC 4.0 API. You must check your driver documentation to be sure that it implements the particular features you want to use.
原文：http://www.cnblogs.com/f1194361820/p/5157098.html