Use JDBC to explain JNDI

JNDI (Java Naming and directory interfaces)

The Naming Service provides an object naming mechanism, so that you can get and use objects without knowing the object location. As long as the object has been registered on the naming server, you must know the address of the naming server and the JNDI name registered on the naming server. You can find the object, obtain its reference, and then use the services it provides.
 

Java Naming and directory interfaces or JNDI provides a public interface for accessing different naming and directory services. See URL java.sun.com/products/jndi/serviceproviders.html to obtain a list of vendors that support access to naming and directory services through the JNDI interface.

JNDI (Java Naming and Directory Interface)
When developing enterprise beans, JNDI is very important because access to an EJB is completed through the JNDI Naming Service. Use a naming service to find an object related to a specific name. In EJB context, a Naming Service finds an enterprise Bean and specifies the bean name. Therefore, it is essential to understand JNDI in developing an EJB application. In addition, JDBC can use JNDI to access a relational database.

Appendix: The JNDI tutorial
Http://java.sun.com/products/jndi/tutorial/index.html
(Download)
Http://java.sun.com/products/jndi/docs.html#TUTORIAL

Jdbc2.0 extended API (1)

[Author: Unknown addition time: 14:11:50]

Source: www.csdn.net

JDBC 2.0 APIs are divided into two parts: JDBC 2.0 core APIs and JDBC 2.0 standard extended APIs. The core API is in Java. SQL. This is the basic function of the original version. The standard extension API is included in javax. SQL. Some interfaces of the new regulations are defined by jdbc2.0. Of course, jdbc2.0 has also made some changes to the original Java. SQL core. But it is not very big. The original jdbc1.0 program can be run on jdbc2.0 without modification. This is a consistent and good style of Java. The latest JDBC package can be downloaded from Sun's website.
Jdbc2.0's extended API adds some important functions for data access and data source access. Some of these are mainly used for enterprise computing. With jdbc2.0's new extension package, JDBC provides a common data access method from the Java2 Platform.
First, let's take a look at how the JDBC standard extended API is combined with jdbc2.0. Jdbc2.0 includes two packages:
1. the java. SQL package contains the core APIs of jdbc2.0. It includes the original jdbc api (JDBC 1.0) and some new 2.0 APIs. This package is available in Java 2 Platform SDK.
2. javax. SQL package, which is the standard extension API of jdbc2.0. This package is brand new and provided separately in Java 2 Platform SDK and Enterprise Edition.
The core APIs of jdbc2.0 include the APIs of jdbc1.0, and some functions are added to improve some performance. The Java language provides a unified data access method at the front end of database computing, and the efficiency is also improved.
JDBC is backward compatible. jdbc1.0 programs can run on jdbc2.0 without modification. However, if the new features of jdbc2.0 are used in the program, it must be run on jdbc2.0.
In summary, the new features of the core JDBC APIs are done in two aspects. One is to support some new functions, and the other is to support sql3 data types.
1. In terms of support for new features: The result set can be rolled back to update data in batches. In addition, stream operations for Unicode character sets are also provided.
2. Support for sql3 data types: including new sql3 data types, and added storage for persistent objects.
To facilitate data access and operations, the new feature of JDBC is easier application design. For example, data block operations can significantly improve database access performance. The newly added blob, clob, and array interfaces can be big data types for application operations, without the need for the client to perform other processing before storage. In this way, the memory usage efficiency is significantly improved.
Next we will introduce the standard extension API of jdbc2.0. Standard extended APIs are divided into the following aspects:
1. datasource interface: the data source interface that works with the Java name Directory Service (JNDI. 2 Connection Pooling (connection pool): You can use the connection again, instead of using a new connection for each request.
3. distrubute transaction: involves multiple database servers in a transaction.
4. rowsets: the JavaBean Component contains a result set, which is mainly used to send data to thin customers or provide a rolling result set.
Next we will introduce them one by one:
I. datasource interface is a better method to connect to the Data source:
Jdbc1.0 was originally used to generate a connection to the data source using the drivermanager class. Jdbc2.0 uses an alternative method. With the implementation of datasource, the Code becomes smaller and more refined, and easier to control.
A datasource object represents a real data source. According to the implementation method of datasource, the data source can be either a relational database, a workbook, or a file in the form of a table. When a datasource object is registered in the name service, the application can obtain the datasource object through the name service and use it to generate a connection with the data source represented by datasource.
Information about the data source and how to locate the data source, such as the name of the database server, the machine on which the data source is located, and the port number are included in the properties of the datasource object. In this way, it is more convenient for the application design, because you do not need to hard write the driver name into the program. The driver name usually includes the name of the driver provider, which is usually used in the drivermanager class. If the data source is to be transplanted to another database driver, the code can be easily modified. All you need to do is change the datasource attributes. The code for using the datasource object does not need to be modified.
The datasource object is configured by the system administrator or a person with corresponding permissions. Configure datasource, including setting datasource properties, and register it to the JNDI name service. When registering a datasource object, the system administrator needs to associate the datasource object with a logical name. The name can be arbitrary. It is usually a name that can represent the data source and is easy to remember. In the following example, the logical name is named inventorydb. By convention, the logical name is usually in the sub-context of JDBC. In this way, the full name of the logical name is JDBC/inventorydb.
Once the data source object is configured, the Application Designer can use it to create a connection to the data source. The following code snippet demonstrates how to use the JNDI context to obtain a data source object and then use the data source object to generate a connection to the data source. The first two rows use the jndi api, and the third row uses the jdbc api:
Context CTX = new initialcontext (); datasource DS = (datasource) CTX. lookup ("JDBC/inventorydb"); connection con = Ds. getconnection ("mypassword", "myusername ");
In a basic datasource implementation, the connection object returned by datasource. getconnection is the same as the connection object returned by drivermanager. getconnection. Because datasource provides convenience, we recommend that you use the datasource object to obtain a connection object. We hope that the database drivers based on the jdbc2.0 technology will contain a basic datasource implementation so that they can be easily used in applications.
For common application designers, whether to use the datasource object is only a matter of selection. However, for Application designers who need to use the connection pool or distributed transactions, the datasource object must be used to obtain the connection. The reason is described below.
2. Connection Pooling (connection pool ):
The connection pool is such a mechanism. When an application closes a connection, the connection is recycled, rather than destroy, because establishing a connection is a resource-consuming operation. If recycled connections can be reused, the number of new connections will be reduced and the running performance will be significantly improved.
Assume that the application needs to establish a connection to the datasource named empolyeedb. Use the connection pool to obtain the connection Code as follows:
Context CTX = new initialcontext (); datasource DS = (datasource) CTX. lookup ("JDBC/employeedb"); connection con = Ds. getconnection ("mypassword", "myusername"); apart from the logical name, we find that the Code is the same as the code in the preceding example. Different logic names allow you to connect to different databases. Whether the connection returned by the getconnection method of the datasource object is a connection in the connection pool depends entirely on the implementation method of the datasource object. If the datasource object works with a server that supports the middle layer of the connection pool, the datasource object automatically returns the connection in the connection pool, which can be reused.
Whether to use the connection pool to obtain a connection is different in the application code. There is no difference in using this connection. The only difference is that a connection is closed in the finally statement block of Java. Closing connections in finally is a good programming habit. In this way, even if the method throws an exception, the connection will be closed and recycled to the connection pool. The Code should be as follows:
Try {...
} Catch (){...
} Finally {If (con! = NULL) con. Close ();}
Iii. distributed transactions:
Obtaining a connection to support distributed transactions is similar to obtaining a connection in the connection pool. Similarly, the difference lies in the implementation of datasource, rather than the method of getting connections in the application. Assume that the implementation of datasource can work with the distributed transaction middle layer server. The connection code is as follows:
Context CTX = new initialcontext (); datasource DS = (datasource) CTX. lookup ("JDBC/employeedb"); connection con = Ds. getconnection ("mypassword", "myusername"); for performance reasons, if a datasource supports distributed transactions, it also supports connection pool management.
From the perspective of Application designers. Whether to support the connection of distributed transactions is no different for it. The only difference lies in the transaction boundary (where a transaction starts and where a transaction ends ), starting or ending a transaction is controlled by the Transaction Server. Applications should not do anything that may impede services. The application cannot directly call the transaction commit or roll back the rollback operation, nor can we use the auto-commit mode of the automatic commit mode of the transaction (the commit or rollback is automatically called when the database operation is complete ).

When a connection participates in a distributed transaction, the following code cannot be performed (con indicates a connection that supports distributed transactions ).
Con. Commit (); or con. rollback (); or con. setautocommit (true); the default connection mode is auto-commit. For connections that support distributed transactions, the default mode is not auto-commit. Note that even if connection supports transactions, it can be used without transactions. Transaction boundary restrictions are only true for distributed transactions.
When configuring datasource that supports the connection pool, it involves configuring the connectionpooldatasource object, which is the middle layer in the three-tier architecture to manage the connection pool. Similarly, when configuring to support distributed transactions, you must configure xadatasource. xadatasource is the intermediate layer used to manage distributed transactions. Connectionpooldatasource and xadatasource are provided by the driver provider and transparent to Application designers. Like the basic datasource, the system administrator configures the connectionpooldatasource and xadatasource objects.
Iv. Result set:
The result set object is the container of a row of data. Based on its purpose, it can be achieved through multiple methods. Rowset and its related interfaces are a little different from the standard extended APIs of jdbc2.0. They are not part of the driver. rowset is implemented at the upper layer of the driver and can be implemented by anyone else.
All types of rowsets implement the rowset interface, and the rowset interface extends the resultset interface. In this way, the rowset object has all the functions of the resultset object. You can use the getxxx method to obtain the value of a column in the database. You can use the updatexxx method to modify the value of a column and move the cursor to change the current row to another row.
Of course, we are more interested in the new functions provided by the rowset interface. As a JavaBean Component, The rowset object can add or delete a listener (listener) and get or set its attribute values. One of these attributes is a string that indicates a query request to the database, the rowset interface defines the parameter setting method and provides the method to execute this request. This means that the rowset object can execute query requests and can be computed based on the result set it generates. Similarly, rowset can be computed based on any table data source. Therefore, it is not limited to relational databases.
After obtaining data from the data source, the rowset object can be disconnected from the data source, and the rowset can also be serialized. In this way, rowset can be transmitted to the thin client over the network.
Rowset can be reconnected to the data source, so that modifications can be saved back to the data source. If a listener is generated, the listener receives a notification when the current row of the rowset is moved or the data is modified. For example, the graphic user interface component can be registered as a listener. When the rowset is changed, the graphic user interface can be modified to conform to the rowset it represents when it receives a notification.
The rowset interface can be implemented in multiple ways based on different needs. Java software has written a cachedrowset implementation, which can be achieved from http://developer.java.sun.com/#/earlyaccess/crs/index.html.
Unlike the cachedrowset class, the jdbcrowset class always maintains a connection with the data source. In this way, a simple layer is added to the peripheral of the resultset. The JDBC-based driver looks like a simple JavaBean Component.

Summary: jdbc2.0 standard extended API is a completely new concept by registering the JNDI name service with datasource. Makes the application code more sophisticated and easy to control. The new API supports connection pools and distributed transactions. Finally, the Java application can spread the result set on the network. Instead, the resultset that cannot be rolled is changed to the rowset that can be rolled.