Chapter 13: JDBC Connectivity administrative and maintenance headaches.
Chapter 13: JDBC Connectivity administrative and maintenance headaches. These drivers are also typically hardware/ OS-specific (because of the data access mechanism that they depend on), making them completely nonportable. . Type II: These drivers are partially written in Java and partially written in native data access languages (typically C or C++). The non-Java portion of these drivers limits the portability of the final code and platform-migration possibilities. The administrative and maintenance burden of Type I still exists. . Type III: These drivers are pure Java drivers on the client side, which gives them the portability benefit of Java. However, they rely on a middleware engine running externally to operate. The client code communicates with the middleware engine, and the engine talks to the different types of databases. The administration and maintenance burden is somewhat reduced, but far from eliminated. . Type IV: These drivers are 100 percent Java and talk directly to the network protocols supported by the RDBMSs. This results in the highest performance connection and the most portable application code. Administration and maintenance are greatly simplified (only the driver needs to be updated). Fortunately, most modern day JDBC drivers are of the Type IV variety. All the major RDBMSs available today (MySQL, Oracle, DB2, and MS SQL Server) have Type IV JDBC drivers available, either through the database vendors themselves or via a third-party driver vendor. Database Connection Pooling When a Web application accesses a remote RDBMS, it may do so through a JDBC connection. Typically, a physical JDBC connection is established between the client application and the RDBMS server via a TCP/IP connection. Establishing such a connection is CPU-, memory-, and execution time intensive. It involves multiple layers of software, and the transmission and receipt of network data. A typical physical database connection may take several seconds to establish. Contrast this with the cost of doing a simple database query, which typically takes milliseconds to complete. It is obvious why it would be wise to decrease the number of connects and disconnects between queries. Modern Web applications consist of JSPs and servlets that may need data from a database on every HTTP request (for example, a JSP that prints the current employees from a specific department, or an electronic auction system that enables you to see all your current open bids). On a well-loaded server, the time it takes to establish, disconnect, and reestablish actual connections (physical connections) can substantially slow down Web-application performance. To create high-performance and scalable Web applications, JDBC driver vendors and application servers are incorporating database connection pooling into their products. Connection pooling reduces expensive session establishment times (connects, disconnects, and reconnects) by creating a pool of physical connections when the system starts up. When an application requires a connection, one of these physical connections is provided. Typically, when an application finishes using a connection, it is disconnected. However, in the case of a logical connection, the associated physical connection is merely returned to the pool and awaits the next application request. Figure 13-2 illustrates database connection pooling.
For high quality website hosting services please check tomcat web hosting website.