Connection Pool - Deeper J2EE Connection SiVA VisvesWaranjavaworld column writer connection is a technology for sharing server resources between requesting clients. This article focuses on support for database resources and non-database resource connections in the J2EE environment. SIVA analyzes JDBC 2.0, JMS 1.02, and JNDI 1.2 to extend the API in connection with the same aspect, and tells some existing suppliers of the API. He then tells the J2EE Connector Architecture 1.0 that is about to appear, support to manage the resource connection with the supplier / can insert. The Java 2 Enterprise Edition (J2EE) specification provides distributed service-based architecture for achieving high scalable, reliable and available e-commerce applications. Typically, J2EE Application Architecture and Model-View-Controller (MVC) framework - Resource Library / External System Resource Support Domain Model (Model), JSP / Servlet Management Display (View), and EJB processing business logic (control . A typical e-commerce application case is implemented through components in all three layers of the server. Considering the huge amount of user interaction (for the application of customers, there are millions), it is necessary to optimize limited server-end resources. Such resources may include databases, message queues, directories, enterprise systems (SAP, CICS), etc., each of them can be accessed by applications using connection objects representing the resource access point. Managing access to shared resources is critical to meeting the high performance demand for J2EE applications. Connection is a technique advocated by a database vendor that allows clients to share a set of cache connection objects that provide access to database resources. In this article, I analyzed the connection between server-end resources (such as databases, messages, directory, and enterprise systems) in the J2EE environment. Why is the resource connection? Consider the code example, where EJB uses JDBC 1.0, not using the connection to access database resources. Obviously, the main problem of this example is the opening and closing of the connection. Considering that entity beans are shared components, it is necessary to obtain and release database connections several times for each client request. As can be seen from Figure 1, obtaining and releasing database connections using JDBC 1.0 will affect the performance of the EJB layer. This impact is caused by the database resource manager process and destroyed those objects. Application servers generally need to spend 1 to 3 seconds to establish database connections (including communication, authentication, etc.) and need to connect to each client (EJB). Figure 1. Connection management using JDBC 1.0
Connections using service provider facilities now look at it now in the J2EE environment, where databases and non-database resource types are currently used which connectivity facilities can be used. JDBC 2.0 Standard Extended APIJDBC 2.0 Standard Extended API Specify database service vendors can implement unique technologies with the following features: Allows the client to transparently sharing multiple connection objects in the resource pool. In that case, since the pool manager creates a connection object in advance, the J2EE component can use the connection object without causing system overhead on the Database Explorer. Application Server Vendor implements pool manager in its memory space and dynamically changing the size of the pool as needed to optimize the use of resources. This is shown in Figure 2. Figure 2. Connection with JDBC 2.0 standard expansion
The J2EE component can get a physical database connection object by using a DataSource interface (JDBC 2.0) or DRIVERMANAGER (JDBC 1.0) interface. To get logical (in use) connections, J2EE components must use the following JDBC 2.0 Co-Division: Javax.Sql.connectionPoolDataSource interface, which acts as a resource manager of the co-use java.sql.connection object. Connect Factory. Each database server vendor provides the implementation of the interface (for example, Oracle implementation Oracle.jdbc.pool.OracleConnectionPoolDataSource class). Javax.sql.pooledConnection interface, which is encapsulated to the physical connection of the database. Similarly, the database vendor provides its implementation. For each of the interfaces and XA connections, there is an equation definition of an XA (X / Open specification). The following code example shows how the EJB application uses a combined connection object to access database resources (based on JDBC 2.0). The EJB components in this example use the JNDI query to determine the location of the database connection pool resource. JNDI 1.2 Standard Extended API allows Java to access objects located in a completely different directory and naming system in the same way. Using JNDI APIs, applications can query directorys to determine where any resources (for example, database servers, LDAP servers, print servers, message servers, file servers, etc.). See "The Java Naming and Directory Interface (JNDI): a more open and flexible model". Note: The actual code may vary depending on the database vendor. The above code (using JDBC 2.0) and the main difference using JDBC 1.0 is: getConnection () Gets open connections from the pool, and Close () only releases the connection object to the pool. Today, almost every database server vendor (such as Oracle, DB2, Sybase, and Informix) provides JDBC 2.0 drivers. Most application server suppliers (IBM, BEA, IPLANET, IONA, etc.) also support JDBC 2.0. It should be explained: Today, almost all application servers use two-layer connection-like architecture, where the pool is located in the application server memory space (different from the independent connection agent). JMS 1.02 Standard Extended APIJ2EE Applications You can use messaging resources to apply asynchronous communication with other enterprises. JMS 1.02 Standard Extended API provides a vendor-wide way to communicate with messaging service providers. Like the database resources, access the message queue by using the connection objects that can be used. The JMS 1.02 API includes the following interfaces to support resource all: Javax.jms.QueueConnectionFactory or javax.jms.queueConnectionFactory, Javax.jms.queueUecConnectionFactory, Javax.jms.QueuecConnection, or Javax.jms.topicConnection JMS service provider implementing those interfaces . The code sample shows how the EJB component uses the connection object to access the message queue resource. When the connection is used, the JMS Factory class usually has a proxy (configured by administrator) so that open () and close () requests actually sent to the agent to manage the connection pool.
Follow the JMS API instructions, the JMS server vendor can implement the database to manage the message queue. In that case, the appropriate JDBC driver will provide a connection. If the application has enabled the database enabled using the JDBC 2.0 connection pool, then you have to configure JNDI features to use the JDBC instance. JNDI API for ldapjavax.naming.ldap package includes LDAP-specific classes (not included in General Javax.naming.directory). Unlike JDBC 2.0 and JMS 1.02 API, JNDI LDAP API does not use any interface to connect to the connection. Directory service providers can choose from SDK. For example, iPlanet the Netscape Directory Server SDK 4.0 for Java LDAP client comprising the construct used class: public class netscape.ldap.util.ConnectionPool extends java.lang.Objectmethods: Connection (), getConnection (), close (), etc .
For more information, see "Netscape Directory Server Application Program's Guide". J2EE Connector Architecture 1.0 In all of the above examples, the EJB component must import a vendor-specific implementation class to use resources connection to use facilities. Obviously, this practice reduces the portability of EJB and is not conducive to the development of J2EE. The ideal approach is to built-in a universal connection interface that can be used for any resource type and all connection management functions (including applications). This is one of the goals of J2EE Connector Architecture 1.0 norms. When I wrote this article, a copy has been published. (See Referring). Figure 3 shows the main concepts inside the architecture, the resource adapter. The plug-in component of each resource type supported by the application server is executed in the application server address space. Accessing the client API of those adapters can be a Common Client Interface (CCI) or (for backward compatibility) API (for example, JDBC 2.0). For example, CCI defines javax.resource.cci.connectionFactory and javax.resource.cci.connection, which are similar to connecting Factory and connection - similar to the JDBC 2.0 interface mentioned in the previous section. Figure 3. Resource adapter in J2EE Connector Architecture 1.0
The programming model of the connection in Connector 1.0 is as follows: EJB executes the JNDI query that connects to Factory and then issues a getConnection () request. Connecting Factory to delegate the request to the ConnectionManager. The connection manager queries the instance of the connection pool in the application server. If there is no connection pool available, the Manager uses ManageDConnectionFactory to create a physical (uncommon) connection. In that case, it is assumed that the resource adapter vendor implements the interface. However, the connector architecture does not specify how the application server implements the connection pool, but provides some indications, for example, according to the adapter type, service quality (QoS) requirements, etc. to divide the pool. For more information, see the J2EE Connector Architecture specification. For example, based on the upcoming EJB 2.0 connector architecture, the product version of the enterprise / old SUN connector, IPLANET Unified Integration Framework Toolkit V 6.0, for each backend system that may be to access for the EJB layer may be connected Pool. A periodically executed thread monitoring pool object usage and life. For more information, see IPLANET Unified Integration Framework. EJB layer design considerations Despite the resource manager management connection pool, it is not guaranteed that the EJB layer has the optimal performance - there are some design considerations! First, consider the following EJB client code example, the client accesss the LDAP directory that implements the connection pool. import netscape.ldap.util *;. ... public class NewCustomerBean implements SessionBean {... private SessionContext context; // Bean Contextprivate LDAPConnection lc; // LDAP Connection object ... public void setSessionContext (SessionContext sc) {this. context = sc; // initialize JNDI lookup parametersContext ctx = new InitialContext (parms); ... ConnectionPool cp = (ConnectionPool) ctx.lookup (cpsource); // Establish LDAP Connection.try {this.lc = cp.getConnection ( );
What is the above practice? First, there is a status session object (NewCustomerbean) Open the connection object in SetentityContext, then continue to take up until it is used until the number of users (session) has increased rapidly, it is considerable implementation. Second, it is also more important because the connection object is not serialized, so according to the EJB 1.2 specification, the container can be discarded when passivated (for example, moving the session bean from its active state to the Bean instance pool). An alternative method is to get and release resource connections in the ejbactivate () and ejbpassivate () methods of session beans, respectively. If there is no connection to the pool, the price will certainly be high, and it will not be advised. However, after the use, use this technology, you can use the smallest EJB layer overhead to get and release the connection. The main point here is that the design choice is always critical performance determine factors in addition to the facilities provided by specifications and implementation. The second consideration is related to certification issues. You may have noticed that a combined connection means that the shared connection, and the shared connection means that the connection is not bound to a specific authentication certificate. For example, in a JDBC 2.0 connection, the Application Server Pool Manager is started, using a authentication certificate stored in the configuration file (usually the user ID / password) to request a preset number of connections from the Database Manager. Sometimes, it may not meet the safety strategy of the application. The LDAP connection needs to bind the LDAP subtree with a specific certificate, and therefore also have the same problem. In those cases, an alternative method may use a high-speed cached connection that utilizes a specific certificate, which can be repeatedly used for the same type of certificate. This method is unfavorable is that the high-speed cached connection is for a long time. Another alternative may be to use a universal connection to resources and achieve some application layer security. Conclusion In this article, I will display the necessary resources in the J2EE environment based on the resource sharing characteristics and access to the EJB components of the resources. You have seen a facility defined by JDBC 2.0, JMS 1.02, and JNDI 1.2 standard, and suppliers support those API interfaces. Although the supplier's solution is very strong, the use of them is the cost of EJB portability. The upcoming J2EE Connector Architecture 1.0 solves the problem and allows resources to be inserted, so that the EJB layer is released from the process specific to the supplier's library. Finally, I explained why your design plays an important role in making high performance J2EE applications using those combination technologies. Reference
