JNDI (Java Names and Directory Interface) JNDI (Java Names and Directory Interface) Distributed Calculation Environment usually uses named and directory services to get shared components and resources. Naming and Directory Services associate names with location, services, information, and resources. Name Service Provides a name-object mapping. Directory services provide information about objects and provide search tools required to locate these objects. There are many named and directory services, and their interfaces are different. Java Naming and Directory Interface or JNDI provides a common interface for accessing different names and directory services. See URL Java.sun.com/products/jndi/serviceProviders.html to get a list of suppliers that support access naming and directory services via JNDI interface. JAVA Naming and Directory Interface When you develop enterprise beans, JNDI is important because access to an EJB is done through 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, given the name of this bean. Therefore, it is important to learn that JNDI is critical in developing an EJB application. In addition, JDBC can use JNDI to access a relational database. Attach: The JNDi Tutorial http://java.sun.com/products/jndi/tutorial/index.html (Download) http://java.sun.com/products/jndi/docs.html#tutorial JDBC2.0 extension The API JDBC 2.0 API is divided into two parts: JDBC 2.0 core API and JDBC 2.0 standard extension API. The core API is in java.sql. This is the basic functionality that is achieved. Standard expansion API inside javax.sql. Some interfaces from JDBC2.0 regulations are in this. Of course, JDBC2.0 also made some changes to the original version of Java.sql. But not very big. The original JDBC1.0 program can not be modified on JDBC2.0. This is a consistent good style of Java. The latest JDBC package can be downloaded from Sun's website. The extended API of JDBC2.0 adds some data access and data source access. There are some in this middle that is mainly used to do business calculations. With JDBC2.0's new extension package, JDBC provides a method of accessing a general data from the Java2 platform. First, let's take a look at how the JDBC standard extension API is combined with JDBC2.0. JDBC2.0 includes two packages: 1, java.sql package, the package is the core API of JDBC2.0. It includes the original JDBC API (JDBC 1.0 version), plus some new version 2.0 of API. This package is in Java 2 Platform SDK. 2, javax.sql package, this is the standard extension API of JDBC2.0. This package is a brand new, provided separately in Java 2 Platform SDK, Enterprise Edition. The core API of JDBC2.0 includes the API of JDBC1.0 and adds some features on this basis to enhance some performance. Make the Java language provide a unified data access method at the front end of the database calculation, and efficiency has been improved. JDBC is backward-compatible, JDBC1.0 program can not be modified on JDBC2.0. However, if the new features of JDBC2.0 are used in the program, they must be running on the JDBC2.0 version. In summary, the new features of the JDBC core API have worked in two aspects. One is to support some new features, the other is to support the data type of SQL3.
1. In supporting new features: including the result set can scroll backward, quantity update data. In addition, a character stream operation of the Unicode character set is also provided. 2, in terms of supporting SQL3 data: including new SQL3 data types, increasing storage of persistent objects. In order to access the data, more convenient operation, the new feature of JDBC is easier to design the application. For example: data blocks can significantly improve the performance of database access. The newly added BLOB, Clob, and array interfaces can be a data type of the application operational block without having to perform other processing before storage. In this way, it has significantly improves the efficiency of the memory. Let's introduce the standard extension API of JDBC2.0. Standard Extended API is divided into the following aspects: 1, DataSource interface: Data source interface works with the Java Name Directory Service (JNDI). It provides a loophochi ā? Br> 2, Connection Pool: You can reuse the connection, instead of using a new connection for each request. 3, Distrubute Transaction: A number of database servers involved in a transaction. 4, Rowsets: JavaBean component contains result sets, mainly to pass data to thin customers, or provide a result set that can scroll. Let's introduce one by one: 1. The DataSource interface is a better way to connect the data source: JDBC1.0 is originally used to use a DRIVERMANAGER class to generate a connection to the data source. JDBC2.0 uses an alternative method to use DataSource's implementation, the code change is smaller and more easily controlled. A DataSource object represents a real data source. According to the implementation of DataSource, the data source can be both a dependency database, also spread, and a file that is also a form of form. When a DataSource object is registered into the name service, the application can get the DataSource object through the name service, and use it to generate a connection between the data source represented by DataSource. About the information of the data source and how to locate the data source, such as the name of the database server, which machine, port number, etc. are included in the properties of the DataSource object. In this way, it is more convenient for the design of the application because it does not need hard to write the name of the driver to the program. Usually the drive name contains the name of the driver provider, and it is usually done in the DriverManager class. If the data source is transplanted to another database driver, the code is also easy to modify. The modifications you need to do are simply changing the relevant properties of DataSource. And the code using the DataSource object does not need to do any changes. The DataSource object is configured by a system administrator or a person with appropriate permissions. Configure DataSource, including setting DataSource's properties, and then register it to the JNDI name service. During the process of registering the DataSource object, the system administrator needs to associate the DataSource object and a logical name. The name can be arbitrary, usually the name that can represent the data source and easy to remember. In the example below, the name is: InventoryDB, according to the 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 generate a connection to the data source.
The following code snippet exemplifies how to get a data source object with a JNDI context, and then how to generate a connection with the data source with a data source object. The starting two lines is JNDI API, the third line is 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 the DataSource.getConnection method and the Connection object returned by the DriverManager.getConnection method is the same. Because DataSource provides convenience, we recommend using the DataSource object to get a Connection object. We hope that the Database drivers based on JDBC2.0 technology contain a basic DataSource implementation so that it can be easily used in the application. For ordinary application designers, whether to use a DataSource object is just a choice problem. However, for applications that need to be used or distributed, you must use the DataSource object to get Connection, which will be mentioned below. Second, Connection Pool: The connection pool is such a mechanism. When the application turns off a connection, this connection is reclaimed, not by DESTROY, because establishing a connection is a very expensive operation. If you can reuse recycled connections, you will reduce the number of newly created connections, significantly improve the performance of the run. Suppose the application needs to create a connection to a DataSource for Empolyeedb. The code to be connected using the connection pool is as follows: context ctx = new initialContext (); DataSource DS = (DataSource) CTX.lookup ("JDBC / EMPLOYEDB"); connection con = ds.getConnection ("mypassword", "myusername"); In addition to the logical name, we found that the code of its code and the example above is the same. Different logical names can be connected to different databases. Whether the Connection returned by the getConnection method of the DataSource object is a connection in a connection pool depends entirely on the implementation of the DataSource object. If the DataSource object is implemented with a server that supports the intermediate layer that supports the connection pool, the DataSource object will automatically return to the connection in the connection pool, which is also repeatedly utilized. Whether to use the connection pool to get a connection, you can't see different on the code of the application. There is no different place to use this Connection connection, the only difference is to close a connection in the Java's Finally statement block. Close connection in Finally is a good program habit. In this way, even if the method throws an abnormality, the Connection is also closed and reclaimed into the connection pool. The code should be as follows: try {...} catch () {...} finally {if (con! = Null) Con. close ();} 3, distributed transaction: get a connection to support distributed transactions The connection in the connection pool is very similar.
Similarly, the difference is that DataSource is different, not what is different in the way in which the connection is obtained. Suppose the implementation of DataSource can work with the supported intermediate layer server to get the connection code or as follows: context ctx = new initialContext (); DataSource DS = (DataSource) CTX.lookup ("JDBC / Employeedb"); Connection Con = DS.GetConnection ("MyPassword", "MyuserName"); due to performance, if a DataSource can support distributed transactions, it can also support connection pool management. From the point of view of the application designer. Whether to support distributed transactions is nothing different, the only difference is on the border of the transaction (where a transaction is started and the place to end a transaction), starting a business or ending a transaction is transaction server To control. Applications should not do anything that may hinder service. The application is not able to directly call the transaction Submit commit or rollback ROLLBACK operations, or you cannot use the Auto Submit mode of the transaction Auto-Commit Mode (automatically call your COMMIT or ROLLBACK) when the database operation is completed. When a connection is involved in a distributed transaction, the following code is what you can't do (ConNeration Connection supports distributed transactions). Con.commit (); or con?setautocommit (TRUE); for the usual Connection, the default is Auto-Commit mode. For Connection that supports distributed transactions, the default is not Auto-Commit mode. Note that even if the connection is supported, it can also be used without transaction. Regarding the restriction of the transaction boundary is only established with a distributed transaction. When configuring DataSource supporting the connection pool, it involves configuring the ConnectionPoolDataSource object, which is the intermediate layer in the three-layer architecture to manage the connection pool. Similarly, when configuring support for distributed transactions, you need to configure XADataSource, XADataSource is an object used to manage distributed things. ConnectionPoolDataSource and XADataSource are transparent by the driver provider, which is transparent to the designer of the application. Like basic DataSource, system administrators configure ConnectionPoolDataSource and XADataSource objects. Fourth, the result set: Results The object is a row of data of the container. According to the purpose, it can be achieved by a variety of ways. RowSet and its associated interface are a bit different from the standard expansion API of JDBC2.0. They are not part of the drive, and RowSet is implemented on the upper layer of driver, which can be implemented by anyone. All types of ROWSET implements the ROWSET interface, and the ROWSET interface extends the ResultSet interface. This RowSet object has a RESULTSET object. You can get a certain value in the database through the getxxx method. You can modify a certain column value via the Updatexxx method. You can move the cursor, which is the current line change to another. Of course, we are more interested in the new features provided by the ROWSET interface.
As a JavaBean component, the RowSet object can add or delete a Listener, you can get or set it attribute values. In these properties, one is a string, indicating a database QUERY request, the ROWSET interface defines setting parameters. The method also provides a method of executing this request. This means that the RowSet object can perform a query request, which can be calculated based on the result set it produces. Similarly, RowSt can also be calculated according to any table data source, so it is not limited to relational databases. After the data is obtained from the data source, the RowSet object can be disconnected and the RowSet can also be serialized. This way, RowSet can be passed to the thin client via the network. The ROWSET can be reconnected to the data source, so that the modifications you can save back to the data source. If a Listener is generated, the listener will receive a notification when the current row of the Rowset is modified. For example, graphical user interface components can be registered as a listener. When RowSet changes, the graphical user interface receives notifications, you can modify the interface to meet the RowSet it represent. According to different needs, the ROWSET interface can be implemented in a variety of ways. Java Software has already written a cachedrowset implementation from http://developer.java.sun.com/developer/earlyaccess/crs/index.html. This implementation can be obtained. Similar to the CachedRowset class is that the JDBcrowSet class always keeps a connection to the data source. In this way, it is simple to add a layer on the surroundings of ResultSet, which is the same as a simple JavabEan component based on JDBC technology. Summary: JDBC2.0 Standard Extended API The JDBC technology expands the JDBC technology into a brand new concept by following seeing DataSource. Make the code's code more delicate and easy to control. The new API supports the connection pool, supports distributed transactions. Finally, the Java application can spread the result set on the network, which is the RSULTSET that cannot be scrolled into rolling RowSet. Tomcat is configured and JNDI JNDI is a very important standard in J2EE. Usually we are used in EJB programming. Tomcat4.0 provides a method of using JNDI directly in JSP and Servelt, talk about Tomcat4.0 Methods for configuring and using JNDI (Take the JNDI connection database as an example) assume that the database is mysql, the experiment example is in the Tomcat_Home / WebApps / dbtest directory A. MM.Mysql's JDBC connection library mm.mysql-2.0.9-bin .jar is put in Tomcat_Home / Common / Lib B. Configure tomcat_home / conf / sere.xml file to join a Context:
This is the root path of dbtest, which is prepared in dbtest. C. Added on it
Segment join
Factory
Org.apache.commons.dbcp.basicDataSourceFactory
Maxactive
100
MaxIdle
30
Maxwait
10,000
Username
Test
Password
Test
Driverclassname
Org.gjt.mm.mysql.driver
URL
JDBC: MySQL: // localhost: 3306 / test
There are English annotations here, which is provided by Tomcat, we can join in Sample, mainly modified DriverClassName, URL, and user account; need to emphasize "JDBC / TestDB" is the Name of JDNI to find. D Using JSPH or Servlet The following is the code in the JSP file for JSP files (files name userHandledb.jsp) Need to note that JNDI Name is to be added "Java: Comp / ENV /" < % @ page language = "java"%> <% @ page import = "java.util. *"%> <% @ page import = "java.sql. *"%> <% @ Page Import = "javax.sql * "%> <% @ page import =" javax.naming. * "%> <% string jndi_name =" java: comp / env / jdbc / testdb "; string select_user_sql =" SELECT Userid, Name, Birthday, Email from EMP "; string colnames [] [] = {{" User ID "," name "," birth day "," email "}, {" userid "," name "," birthday "," email "}}; Vector useerSet = new vector (); vector columnset = new vector (); for (int i = 0; ie. Reference userHandledb.jsp (Remember to viewTable.jsp)
Test Database <% @ include file = "UserHandledb.jsp"%>
"); for (int J = 0; J
" COL " ");} out.print (" ");}%>
<% for (int i = 0; i
F. Add to Web.xml
DB Connection
JDBC / TESTDB
Javax.sql.datasource
Container
The Name of the JDBC / TESTDB and the Name of the resource segment in C, the observation first determines that the database has been started, then start Tomcat, if Tomcat starts an exception, the possible reason is that the database's JDBC library does not load finally open the browser, access HTTP : // localhost: 8080 / dbtest / viewtable.jsp You can see the result
