On the necessity of the connection pool of JSP database

js| Data | database | Database connection in general, when using a web-based Web application, the traditional pattern is basically the following steps:
　　
1. Establish a database connection in the main program (such as Servlet, Beans).
　　
2. Perform SQL operations to remove data.
　　
3. Disconnect the database.
　　
There are a number of problems with developing this pattern. First, we want to establish a database connection for every Web request, such as viewing the content of an article. For one or more operations, you may not be aware of the overhead of the system, but for Web applications, even within a short period of time, the number of operation requests is far less than one or two times, It's dozens of hundreds of times (think of people all over the world who are likely to find data on your Web page), in which case the overhead is quite large.
　　
In fact, in a database based Web system, establishing a database connection is one of the most costly operations in the system. Most of the time, it's possible that your site's speed bottleneck is this.
　　
Second, using the traditional pattern, you have to manage every connection, make sure that they can be shut down properly, and that some connections fail to shut down if a program exception occurs, causing memory leaks in the database system, and eventually we will have to restart the database.
　　
To solve the above problem, we first think that we can adopt a global connection object, not closed after it is created, so that the program will use it all the time, so there is no problem of creating and shutting down the connection. However, excessive use of the same connection can cause the connection to become unstable and, in turn, cause a frequent restart of the Web server.
　　
Therefore, this method is also not desirable. In fact, we can use connection pooling technology to solve these problems. First, introduce the basic principle of connection pooling technology. As the name suggests, the basic idea of a connection pool is to build some connections in a memory object for use in advance:
　　 　
As shown in the figure, when you need to establish a database connection in your program, you only have to take one from memory and not create new ones. Again, after use, simply put back the memory. And the connection of the establishment, disconnect are connected to the pool itself to manage. We can also control the number of connections in the connection pool, the maximum number of times per connection, and so on, by setting the parameters of the connection pool. By using connection pooling, the program efficiency is greatly improved, and we can monitor the number and usage of database connections through its own management mechanism. Here we take a connection pool named ConnectionPool to see the implementation of the connection pool. First look at the basic properties of ConnectionPool:
　　
M_connectionpoolsize:
Lower number of connections in connection pool
M_connectionpoolmax:
Maximum number of connections in connection pool
M_connectionusecount:
Maximum number of times a connection is used
M_connectiontimeout:
Maximum idle time for a connection
M_maxconnections =-1:
Maximum number of connections at the same time
M_timer: Timer
　　
These properties define the valid status values of the connection pool and each of these connections. The self-management of the connection pool, in fact, is through the timing of the status of each connection, the number of connections to the corresponding operation. The management process is as follows:
　　 　
With the above diagram, we can define the basic interfaces that connectionpool need to complete management:
　　
public class ConnectionPool
Implements TimerListener
{
public Boolean Initialize ()
Connection Pool Initialization
public void Destroy ()
Destruction of connection Pools
Public synchronized Java.sql.Connection
Getconnection ()
Take a connection
Public synchronized void Close ()
Close a connection
Private synchronized
void Removefrompool ()
Remove a connection from the connection pool
Private synchronized
void Fillpool ()
Maintain Connection Pool Size
Public synchronized
void TimerEvent ()
Timer event handler function
}
　　
With these interfaces, the basic management of connection pooling can already be completed. The stateful inspection of the connection pool is completed in the Timeevent () function, and the connection pool remains at least the minimum number of connections when Fillpool (). Because we want to save the status of each connection, we also need a database connection object:
　　
Class Connectionobject
{
Public java.sql.Connection con;
public Boolean inUse;
Whether the flag is used
public long lastaccess;
Last time to start using
public int usecount;
Number of times to be used
}
　　
After adding the Connectionobject object, the ConnectionPool should only be connectionobject, and the other process needs only the Connectionobject con attribute, so we add a class, To obtain an interface with a return connection as another process:
　　
CLASS Conn
{
Getconnection ();
Remove a valid connection from the connection pool
CloseConnection ();
Returns the connection, the connection is not closed at this time, but the connection pool is put back
Destroypool ();
Destroying connection pools
}
　　
Finally, the overall architecture of our system is as follows: