Overview of the new features and improvements of JAVA Database 3.0 Code JOSH Heidebrecht (JHeiDebr@ca.ibm.com) Software Engineer, IBM JAVA Database Connection (Java Database Connectivity, JDBC) API is a standard version of Java 2 ( Java 2 Standard Edition, J2SE) and Java 2 Enterprise Edition (JAVA 2 Enterprise Edition, J2EE) platform appear. It is a primary standard mechanism that allows the Java language to access the relational database by programming, so developers will be interested when Java Community Process issues a new version of the specification. Here, we summarize some of its new main features on the Proposed Final Draft version 3.0 for the recently released JDBC specification of Sun Microstems. Join the discussion forum, share your views on this article with author and other readers. Introduction to the Java Database Connection (JDBC) 3.0 specification is based on its original stable, adding several new features to make up for the lack of insufficient features. Whether java.sql or the first Javax.sql package, will be included in the Java 1.4 version of the test phase. It will be officially released later, and Java developers can use these improvements, so it is now a good time to learn about these changes.
We will simply discuss several design goals for JDBC designers for this release. Understand the basic principles of designers, we can better understand those changes. We will summarize several new features in the specification to understand how the entire API is changed. In addition, we will also study several key functions that best applicable developers to successfully assist you with its new performance.
The original intention of the design objectives design JDBC 3.0 is mainly more perfect for the original JDBC specification. Therefore, one of the new standard guidelines is to maintain compatibility with existing applications and drivers. Therefore, the user of JDBC 2 can rest assured that their application can run correctly in JDBC 3.0. In addition, the code that is written into the JDBC 1 API using the previously opposed method can also continue to run.
As the J2EE platform is rapidly increasing, designers also want to enhance the scalability of JDBC. The new statement pool and enhanced connection pool support are far from achieving this goal. In addition, designers also carefully consider the relationship between JDBC and new connector architecture to continue to increase Java technology on the server.
In the process of JDBC 2 development, SQL99 is still in a variety of changes. The norms are now completed, and the database manufacturers have adopted some standards. So naturally, the JDBC specification follows part of the SQL99 functionality. The latest JDBC specification has adopted those features that have been widely supported in SQL99 standards, as well as those that may be supported within five years.
If a database does not support the part of the SQL99 function supported by JDBC 3.0, the driver can use the metadata API to show that the underlying database does not support a part of JDBC function. This allows database vendors to produce the corresponding JDBC drivers, although they may not support all functions. Increased new data types, as well as SavePoint support for transactions, indicating two changes related to SQL99.
New function summary
The metadata API metadata API has been updated, and the DatabaseMetadata interface can now retrieve the hierarchy of the SQL type, a new ParameterMetadata interface to describe the type and properties of the parameters in the PreparedStatement object. The named parameter in CallableStatements is before JDBC 3.0 sets a parameter in a stored procedure to specify its index value instead of its name. The callablestatement interface has been updated, and now you can use the name to specify the parameters.
Data types change the data types supported by JDBC, one of which is increasing two new data types.
In order to facilitate the modification of the value of Clob (Character Large Object, Character Music), Blob (Binary Large Object, Binary Object), and REF (SQL Structure) type, the same name's data type interface is updated. Next, because we can now update the value of these data types, the ResultSet interface is also modified to support the update of columns of these data types, including updates to the Array type.
The added two new data types are java.sql.types.datalink and java.sql.types.boolean. The new data type refers to the same name of the SQL type. Datalink provides access or URL of external resources, while the Boolean type is logically and bit types, just increasing the meaning of semantics. The Datalink column value is retrieved from an instance of the ResultSet using the new getURL () method, and the Boolean type is retrieved by using getBoolean ().
Retrieving Automatically generated keyword In order to resolve the need to obtain the value of the automatic or automatic increasing keyword, the JDBC 3.0 API will now get this value easier. To determine the value of any keyword, as long as you specify an optional tag in the execute () method of the statement, you are interested in getting the resulting value. You are interested in the extent that statement.return_generated_keys can also be statement.no_generated_keys. After performing this statement, the value of the keyword generated will be obtained by retrieving the ResultSet by getgeneratedKeys () from statement. The ResultSet contains columns of each resulting keyword. The example in Listing 1 creates a new author and returns the corresponding automatic keyword.
Listing 1. Retrieving automatic keywords
Statement Stmt = conn.createstatement ();
// Obtain the generated key That Results from the query.
Stmt.executeUpdate ("INSERT INTO Authors"
'(First_name, last_name "
"VALUES ('George', 'ORWELL'",
Statement.return_Generated_Keys);
ResultSet RS = stmt.get generatedKeys ();
IF (rs.next ()) {
// Retrieve The Auto Generated Key (s).
Int key = rs.getint ();
}
Most application developers do not need to know the relationship between JDBC and J2EE linkage architectures, you can use JDBC APIs. However, since the JDBC 3.0 specification has taken into account this new architecture, this makes developers better understand where JDBC is suitable for J2EE standards, and what is the development direction of this normative. The J2EE linkage architecture specifies a set of protocols that allow the company's information system to connect to the application server in an insertable manner. This architecture defines a resource adapter that is responsible for connecting to an external system. The ConnectorS Service Provider Interface (SPI) is closely fitted with the service provided by the JDBC interface.
The JDBC API implements two of the three protocols defined by the linkage architecture. The first is the connection management that connects the application component to the backend system, which is implemented by the DataSource and ConnectionPoolDataSource interface. The second is to support transaction management of transactional access to resources, which is processed by XADataSource. The third is to support security management of secure access of the backend system. At this point, the JDBC specification does not have any corresponding points. Although there is a last deficiencies, the JDBC interface can still be mapped to the connector SPI. If a driver vendor maps its JDBC driver to the connector system protocol, it can deploy their drivers as a resource adapter and immediately enjoy the benefits of deployment in the application server. In this way, a standard API can be used by enterprise developers in different types of corporate information systems.
ResultSet maintains a remarkable cursor (or result), that is, the cursor is not automatically turned off after the transaction contains its transaction. JDBC 3.0 adds support for the maintenance of the specified cursor. To develop your RESULTSET's remarkability, you must use createStatement (), prepareStatement () or prepareCall () method to prepare to write a statement. The maintenanceability can be one of the following constants.
Hold_cursors_over_commit resultSet object (cursor) is not closed; they remain open after the submission operation is explicitly or implicit. Close_cursors_at_commit resultset object (Cursor) is closed after the submission operation is explicitly or implicit.
Overall, closing the cursor operation after the transaction is submitted to bring better performance. Unless you need this cursor after the end of the transaction, you'd better close it after the submission is performed. Since the specification does not specify the default retainability of the Resultset, the specific behavior will also depend on the execution. However, I hope that when I can use the JDBC 3.0 driver, most execution will still close the cursor after the end of the transaction.
Any limitation of returning multiple results JDBC 2 specification is that in any time, the statement that returns multiple results can only open a resultset. As a part of the JDBC 3.0 specification, the specification will allow the Statement interface to support multiple open Resultsets. However, it is important that the execute () method will still close the ResultSet in any previous Execute () call. Therefore, to support multiple open results, the Statement interface is to add a heavy-duty GetMoreResults () method. The new method will make an integer tag, and the result is specified when the getResultSet () method is called when the previously opened ResultSet behavior. The interface will be tagged as shown below:
Close_all_results When the getMoreResults () is called, all previously opened ResultSet objects will be turned off. CLOSE_CURRENT_RESULT When Toned GetMoreResults (), the current ResultSet object will be turned off. Keep_Current_Result When calling getMoreResults (), the current RESULTSET object will not be closed. Listing 2 shows an example of processing multiple open results.
Listing 2. How to handle multiple open results
String procall;
// set the value of procall to call a stored procedure.
// ...
Callablestatement cstmt = connections.preparecall (ProcCall);
int RetVal = cstmt.execute ();
IF (retval == false) {
// The Statement Returned An Update Count, SO Handle IT.
// ...
Else {// Resultset
ResultSet RS1 = CSTMT.GETRESULTSET ();
// ...
RetVal = cstmt.getmoreresults (statement.keep_current_result);
IF (retval == true) {
ResultSet RS2 = cstmt.getResultSet ();
// Both ResultSets Are Open and Ready for use.
Rs2.next ();
Rs1.next ();
// ...
}
}
Connecting pool JDBC 3.0 defines several standard connection pool properties. Developers don't need to use API to modify these properties directly, but are implemented by applying servers or data storage devices. Since developers are only affected by standardization of the pool attributes indirectly, it is not obvious. However, by replacing the number of properties of vendors and replacing them with standardized properties, developers can be more easily exchanged between different vendors' JDBC drivers. In addition, these properties also allow administrators to optimize the connection pool to make the performance characteristics of the application to the extreme. These properties are shown below.
Property Name Description The maxStatements connection pool can keep the number of statements. InitialPoolSize can be established by the pool initialization. The MinPoolSize pool can contain the minimum number of physical connections. The maxpoolsize pool can contain the maximum number of physical connections. Zero does not have a maximum. MaxIdletime duration, in seconds, refers to the time that a idle physical connection can stay in the pool before being closed. Zero means no limit. PropertyCycle interval, in seconds, refers to the time that the connection pool can wait before performing its properties policy.
In addition to improving the support of the connection pool, preparatory statements can now buffer preparatory statements. The preparatory statement allows you to use a common SQL statement and then prepare it, so that the performance is greatly improved in this statement. In another aspect, establish a prepaaredStateMent object will bring a certain amount of system overhead. Therefore, in the ideal case, the life cycle of this statement should be long enough to compensate for the system overhead it brought. The pursuit of performance developers sometimes distort their object model in order to extend the life cycle of PreparedStatement objects. JDBC 3.0 allows developers no longer worrying, because the data source layer is now responsible for cache for preferences.
Listing 3 will demonstrate how to use JDBC support for the preparatory statement. Careful readers may find that the statement in the list and the code of ordinary JDBC 2 are not available. This is because the buffering of the statement is completely implemented inside. This means that in JDBC 3.0, your existing code can automatically utilize the statement pool. But unfortunately, this also means that you will not control which preparatory statement will be buffered, but only the number of cached statements can be controlled. Listing 3. Buffer preparation statement
String insert_book_query = "Insert Into Booklist"
'(Author, Title)
VALUES (?,?) ";
Connection conn = apooledconnection.getConnection ();
PreparedStatement ps = conn.preparestatement (INSERT_BOOK_QUERY);
Ps.setstring (1, "ORWELL, George";
Ps.setstring (2, "1984");
ps.executeUpdate ();
ps.close ();
CONN.CLOSE ();
// ...
CONN = apooledConnection.getConnection ();
// Since The Connection Is from a PooledConnection, The Data Layer HAS
// The option to Retrieve this Statement from Its Statement Pool,
// Saving The VM from Re-Compiling The Statement Again. // SAVING THEMEN.
PreparedStatement CachedStateMent = conn.prepareStateMet (Insert_book_query);
// ...
Using SavePoint in your business may be the most exciting additional feature in JDBC 3.0 is SavePoint. The transaction support in JDBC 2 allows developers to control concurrency access to data, thereby ensuring that persistent data is always consistent. It is a pity that sometimes it is more control over the transaction, not a change in each change in the current transaction. Under JDBC 3.0, you can get this control via SavePoint. The SavePoint interface allows you to split transactions into individual logical breakpoints to control how many transactions need to roll back. Figure 1 illustrates how to use SavePoint in the transaction.
Figure 1. Intuitive representation of SavePoint
You may not often need SavePoint. However, in a common case, SavePoint will play, that is, you need to make a series of changes, but you cannot determine which part of these changes should be retained before you know all the results. The code example in Listing 4 illustrates how to use the SavePoint interface.
Listing 4. Using SavePoint
Conn.setautocommit (false);
// Set a Conservative Transaction Isolation Level.
Conn.settransactioniSolation (connection.transaction_serializable);
Statement Stmt = conn.createstatement ();
Int rows = stmt.executeUpdate ("Insert Into Authors"
'(First_name, last_name) Values "
'(' Lewis', 'Carroll') ");
// set a named savepoint.
SavePoint svpt = conn.setsavepoint ("newauthor");
// ...
Rows = stmt.executeUpdate ("Update Authors Set Type = 'FICTION'"
"Where last_name = 'carroll');
// ...
Conn.rollback (svpt);
// ...
// The Author Has Been Added, but not updated.
CONN.COMMIT ();
Conclusion JDBC 3.0 is now under testing period, and the official release is set in the second half of 2001. The main database vendors are working on providing JDBC 3.0 drivers, and some early beta drivers have been available. Although the change in JDBC 3.0 is essentially revolutionary, it is also a very important progress. Through the existing functional extension, the new JDBC specification gives you a new policy to resolve your relationship database.
Reference
Join the discussion forum of this article.
Please read the JDBC specification or download the latest JDBC API.
Please read the connector architecture specification.
Please visit the J2EE home page.
Please visit the J2SE 1.4 beta home page.
John Zukowski In his progressive developerWorks column, Merlin's magic involved some of the selection of important parts of the Java 1.4 beta.
At June Javaone meeting, John Zukowski participated in several reports of Java 1.4 beta (Merlin), and elaborates the import part of DeveloperWorks in "Java 1.4, next wave".
IBM Red Book "IBM WebSphere and Visualage for Java Database Integration with DB2, Oracle, And SQL Server" describes how to integrate relationship database systems with web servers.
Lotus SQL / JDBC Applet is a data access applet that allows you to read, modify, and publish data from external databases.
LENNART J? Elid discusses the Java mode using the server-side JAVA mode by JDBC in "Uses, Part 1" (United States, 2000). In Part 2 (DeveloperWorks, February 2000), he describes how to use a mass-oriented data technology to get multiple ResultSet objects.
Please visit the DeveloperWorks Java technology area to get more Java reference materials.
