On the weekend test, I was overlooked two times (more than 1200 pages, I relying on), which mentioned the JDBC connecting pool, is interested, because my VC-ADO program can also consider implementing a simple connection pool. use. There are several features of the ADO connection: 1. It is not a thread. It is easy to cause a transaction dead lock. Generally, single SQL will not be dead, but it is easy to die, so the general multi-threaded program does not advocate reusing the same ADO Connection2: ADO will manage the OLEDB connection pool to call the Connection's Close Method, just put the connection in the pool until the timeout or program is closed. In general, a connection created by a program uses the same connection string will be automatically pool. ADO.NET can clear whether or not to use the pool. 3: If you use a smart pointer_connectionprt, its Close mode is just a closed connection (put it in the pool) without release the object. 4: But if you have never been called, this connection cannot be shared by other threads / processes. 5: When a connection is busy, the program requires the operation on the connection, ADO actually opens a temporary connection for use. The reason why considering the ado connection pool, mainly to perform some simple SQL (such as INSERT, DELETE ..), do not need to create a lot of ADO Connection objects. Also casually record some elements you want to consider: 1: Pihua. Includes batch initialization and release connections. You can design a busy / idle queue management, a call, remove one from the idle queue, and put it in the busy queue; or use the loop array to manage. It is preferred to use the latter because the maximum number of connections in the former cannot exceed the queue size, and in fact each connection can be multiplexed by the client. The purpose of the number management is to get the minimum connection in the connection pool. 2: Give the client unified acquisition and release interface. Pool.getConnection This is a good understanding. You can also define a pool.releaseConnection (Connection) interface, but the client code is inevitably invoked for CONNECTION.CLOSE (even if it is forbidden). The best way is to implement or reload the Connection interface, take over or shield close. Making the default action of the Close is to return the connection to POOL to be used (or reduce usage). 3: Detect transactions on the connection finished condition. Cross execution transactions in a multiplexed connection should not be. Another transaction is not allowed when a transaction is not performed (implemented by the internal lock). But the code currently written is basically not used in Transaction, so it is not anxious. 4: From 2 can be seen, it is best to define a PooledConnection interface, the client is operated on the interface instance, not directly to the Connection object, so that some of the control logic of the pool is better. But this is also involved in synchronous maintenance between interfaces and objects. It is best to implement the method of inheritance, except for the open closing, etc., directly affects the interface of the connection status, or to the client's direct control interface. 5: The connection pool should detect the connection status of the Connection, and the disconnected connection should be tagged or removed directly from the connection pool.
