Application from a ConnectionPool implementation of Design Pattern (1)

zhaozj2021-02-16  46

Application from a ConnectionPool implementation of Design Pattern (1)

What is ConnectionPool? We know, JDBC offers Java.sql.connection Interface for our connection to different data sources. However, because connecting the connection with the database is a big overhead, we can cacked the open database connection to a connection pool for subsequent Connection users. After the user is used, it returns it to the connection pool.

There are many functions to consider a connection pool.

1. If you set up a maximum number of connections to ensure that the database will not be paralyzed due to excessive connection requests;

2. Whether to set a minimum connection to ensure that there are at least several connections available at any time;

3. Whether to set up a maximum of the number of idle connections, the idle connection exceeds this number to close too much connection;

4. When the request for a connection cannot be satisfied, is it waiting to be synchronized or returned directly.

5. How to guarantee fairness, that is, a synchronization request for the connection will get the X response within a certain period of time, not hungry.

6. The connection pool is implemented with a Vector, List or other Collection object.

Etc., etc.

Below, let's take a look at a ConnectionPool implementation:

Public class connectionpool {

PRIVATE FINAL Vector POOL = New Vector ();

PRIVATE INT Clients;

Private int maxclients;

Some of the other connection properties such as UserName, Password, DSN, etc.

Public synchronized connection getConnection () {

If there is a Connection in pool

Remove a connection conn from the pool;

CLIENTS ;

Return conn;

Otherwise, if Clients

Generate a new connection CONN

CLIENTS ;

Return conn;

Otherwise, Wait () until there is idle connection in pool

}

Public Synchronized Void CloseConnection (Connection Conn) {

Pool.Add (conn);

Clients -;

NOTIFY ();

}

Public synchronized void clear () {

For Each Connection in Pool

CONN.CLOSE ();

Pool.removeAllelements ();

}

}

Ok, let's take a look at anything can improve.

First, there are many different considerations for the implementation of ConnectionPool, which is obviously just a fairly simple implementation. So, should we implement according to the strips listed above?

No, if so, we have made a mistake of over-design. Maybe we don't need that complex function now, why do you want to find trouble? Moreover, some features are not simple and bad, and it is necessary to change according to the specific needs. Some people may say, ok, I put some Boolean variables in the class, and I can configure for each function. I maybe it, but you still have to write code for each function, and finally this connectionPool becomes A spaghetti. Moreover, guys make us modest! "Not I don't understand, this world is fast", we have to admit that we will never predict all the possibilities. It is impossible to implement all the needs into a class. So, what about "first"? Anyway, it is also simple, "Simple and Stupid". Isn't this good? The problem is, we have to consider using our ConnectionPool to get users. Although demand may vary multiple ends, we should also provide users with a fixed interface as much as possible. You can't ask for this programmer using your ConnectionPool: "Hey, buddy, I wrote a connectionpool2 yesterday, more than CONNECTIONPOOL, you change this. Repelace all."

Therefore, we should design ConnectionPool as an interface, so that users who use ConnectionPool Interface may not be affected regardless of how the category changes. They can even use different ConnectionPool implementations as needed. Simple, is it? Not an interface. Believe me, how much do you see it?

Second, a good ConnectionPool should be transparent to the user of Connection. For a user who uses Connection Interface, such as:

Void DoQuery (Connection Conn) {......

It should have the Connection from ConnectionPool insensitive.

So, how do we release Connection when not using ConnectionPool? Yes, it is called Connection.Close (). We should not ask the user to modify the connectionPool.CloseConnection to release the connection.

Third, suppose we have two connectionpool objects, a connected Oracle database, another connection SQL Server. Now, the user uses two connectionPool at the same time, when the user is used, he accidentally calls SQLPool.CloseConnection (OrClpool); OrclPool .CloseConnection (SqlConn);

God! Others bombs! Don't blame the programmer: "That kind of only knows how to relieve the class library, there is no library's protection. I don't know how to program the programmer." In fact, this is completely your fault.

Ok, how is foreried out, please follow the decomposition. Homework is, please go back to think about how to design this connectionpool.

转载请注明原文地址:https://www.9cbs.com/read-26051.html

New Post(0)