Use tomcat-5.5.20 to configure the database connection pool

This article aims to provide program developers with a more specific Tomcat connection pool reference solution. To improve the readability of the article, the front-end of the article cited a predecessor. If there is a misunderstanding, please forgive me, this article is not from commercial considerations. If you have any questions, contact the author MSN: hpj2001 (AT) hotmail.com and Email: tocow (AT) Google.com.

Connection Pool Introduction
There are many problems in program development: first, each Web request requires a database connection. Establishing a connection is a time-consuming activity, and it takes seconds each time ~ 1 S, and the system also needs to allocate memory resources. This time may not feel the system overhead for one or several database operations. However, for today's Web applications, especially large e-commerce websites, it is normal that hundreds or even thousands of people are online at the same time. In this case, frequent database connection operations will inevitably occupy a lot of system resources, and the website's response speed will inevitably decrease, which may even cause server crashes. This is a technical bottleneck restricting the development of some e-commerce websites. Second, each database connection must be closed after use. Otherwise, if the program fails to be closed due to an exception, the memory in the database system may leak and the database will have to be restarted. In addition, such development cannot control the number of connection objects to be created, and system resources will be allocated out without consideration. For example, too many connections may also cause memory leakage and server crash.
How the connection pool works:
From the above analysis, we can see that the root cause of the problem is the inefficient management of database connection resources.
There is a well-known design pattern for shared resources: resource pool ). This mode is designed to solve the problems caused by frequent resource allocation and release. To solve the above problems, you can use the database connection pool technology. The basic idea of the database connection pool is to create a "buffer pool" for the database connection ". A certain number of connections are put in the buffer pool in advance. When you need to establish a database connection, you only need to extract one from the "buffer pool" and put it back after use. We can set the maximum number of connections in the connection pool to prevent endless connections to the database. More importantly, we can monitor the number and usage of database connections through the connection pool management mechanism to provide a basis for system development, testing and performance adjustment.

I. Tomcat General description
1. tomcat in this compressed package is Apache-Tomcat-5.5.20. As of, it is the latest tomcat version on www.apache.org.
2. Tomcat uses the default port. Two important ports: shutdown port: 8005; non-ssl http/1.1 Connector port: 8080.
3. Files involved in modification:
A../conf server. XML and Web. xml
B../common/lib. Add the MS-SQL JDBC jar packages msbase. jar, MSSQLServer. jar, and msutil. jar.
Ii. Tomcat connection pool configuration Solution
This article describes the connection pool of Tomcat 5.5. Other versions may not apply.
The data source can be configured globally and locally: the global data source can be referenced in any context. The data source configured in a context cannot be referenced in other context. After understanding the relationship between global data sources and local data sources, we will introduce the detailed configuration instructions as follows:
1. Edit and open./confcatalina/localhost/gdczsam. xml. You can see:
<! -- F hpj 2006-10-12
Defualt, we set all different resources as global-resource [which defined in server. xml <globalnamingresources> </globalnamingresources>],
And get special resource we needed in per-web-application contexts from global-resource.
Otherwise, we can set resource we needed in any special context, all two solutions are offered.

A. During application development set reloadable = "true", when deployed production set reloadable = "false"

B. Export other datebase, URL and driverclassname like underside list:
1. MS-SQL driverclassname = "com. Microsoft. JDBC. sqlserver. sqlserverdriver"
Url = "JDBC: Microsoft: sqlserver: // 127.0.0.1: 1433; databasename = sam_gdcz"

2. Oracle driverclassname = "oracle. JDBC. Driver. oracledriver"
Url = "JDBC: oracle: thin: @ 127.0.0.1: 1521: sam_gdcz"

3. PostgreSQL driverclassname = "org. PostgreSQL. Driver"
Url = "JDBC: PostgreSQL: // 127.0.0.1: 5432/sam_gdcz"

4. MySQL driverclassname = "org. gjt. Mm. MySQL. Driver" [old MySQL JDBC driver]
Driverclassname = "com. MySQL. JDBC. Driver"
Url = "JDBC: mysql: // 127.0.0.1: 3306/sam_gdcz"
-->

<Context docbase = "setup directory" Path = "/gdczsam" reloadable = "true" cookies = "true" crosscontext = "true" privileged = "true" antiresourcelocking = "false" antijarlocking = "false">

<! --
<Resource Name = "JDBC/mssql-SAM_GDCZ"
Auth = "Container"
Type = "javax. SQL. datasource"
Driverclassname = "com. Microsoft. JDBC. sqlserver. sqlserverdriver"
Url = "JDBC: Microsoft: sqlserver: // 127.0.0.1: 1433; databasename = sam_gdcz"
Username = "sa"
Password = ""
Maxidle = "30"
Maxwait = "10000"
Maxactive = "100"/>
-->

<! -- F hpj 2006-10-12
Name: the name of the resource link to be created, which will be used in this web-application context environment.
Global: The name of the linked global resource in the global JNDI context.
Type: The fully qualified Java class name expected by the web application when it performs a lookup for this resource link.
-->
<Resourcelink name = "mssql-SAM_GDCZ" Global = "JDBC/mssql-SAM_GDCZ" type = "javax. SQL. datasource"/>

</Context>
The default configuration of the Tomcat connection pool provided in this article is shown in the preceding figure. The code description is very strong, both in. /CONF/server. the global data source configured in XML, and then the method called in the specified context.
The data source in server. XML is the resource node annotated by the preceding code snippet and is included in the globalnamingresources node in server. xml.
Note that the data source must be declared in./CONF/Web. XML as follows:
<Resource-ref>
<Description> dB connection </description>
<Res-ref-Name> JDBC/mssql-SAM_GDCZ </RES-ref-Name>
<Res-type> javax. SQL. datasource </RES-type>
<Res-auth> container </RES-auth>
</Resource-ref>
2. The second Tomcat data source configuration method is recommended by myself: The resource node is not added to the globalnamingresources node of server. XML, but the data source is configured for each specified context, so that the structure is clear. The configuration of gdczsam. XML in this way is as follows:
<Context docbase = "setup directory" Path = "/gdczsam" reloadable = "true" cookies = "true" crosscontext = "true" privileged = "true" antiresourcelocking = "false" antijarlocking = "false">

<Resource Name = "JDBC/mssql-SAM_GDCZ"
Auth = "Container"
Type = "javax. SQL. datasource"
Driverclassname = "com. Microsoft. JDBC. sqlserver. sqlserverdriver"
Url = "JDBC: Microsoft: sqlserver: // 127.0.0.1: 1433; databasename = sam_gdcz"
Username = "sa"
Password = ""
Maxidle = "30"
Maxwait = "10000"
Maxactive = "100"/>

</Context>
3. In the preceding two methods, the resource-ref Declaration must be added to./CONF/Web. XML as long as the data source is different.
4. During product deployment, you must add a file similar to gdczsam. XML in./confcatalina/localhost to configure the data source no matter how you deploy the program.