Application from a ConnectionPool implementation of Design Pattern (2)
Ok, let's take a look at how we designed this ConnectionPool interface.
Public interface connectpool {
CONNECTION getConnection ();
Void clear ();
}
Of course, this is just a simplified interface. Perhaps we will have some other ways. Synchronize getConnection () and asynchronous getConnection () are supported at the same time.
At the same time, this returned Connection must rewrite the Close () method. The original close () method is to close the physical connection, but now we have to return this connection to ConnectionPool. Therefore, this Connection object must know the ConnectionPool it is born.
In this way, the user still calls connect.close (), nor isn't worrying about returning the connection to the wrong ConnectionPool.
Let's take a look at our implementation:
Public Class ConnectionPoolImpl: Implements ConnectionPool {
Class PooledConnection Implements Connection {
PRIVATE FINAL CONNECTION CONN;
Private boolean closed;
Public PooledConnection (Connection CONN)
Throws sqlexception {
THIS.CONN = conn;
Closed = conn.isclosed ();
}
Public void close () {
IF (! CLOSED) {
/ / Ensure that the repeated call close () does not returns a connection again.
CloseConnection (CONN);
Closed = true;
}
}
Public boolean isclosed () {return closed;}
Public Statement CreateStatement ()
Throws SqlConnection {
IF (isclosed ()) throw new sqlexception ("Connection Closed");
Return conn.createstatement ();
}
Public void commit ()
Throws SqlConnection {
IF (isclosed ()) throw new sqlexception ("Connection Closed");
CONN.COMMIT ();
}
// All other methods are trust in this way.
}
Public synchronized connection getConnection () {
If there is a Connection in pool
Remove a connection conn from the pool;
CLIENTS ;
Return New PooledConnection (CONN);
Otherwise, if Clients Generate a new connection CONN CLIENTS ; Return New PooledConnection (CONN); Otherwise, Wait () until there is idle connection in pool } // Other implementations are the same as the code in our first chapter. } Ok, so, through the internal class PooledConnection such a Wrapper, we can implement this ConnectionPool's Connection. Yes, I forgot to say, this PooledConnection is actually the Decorator mode in Design Pattern. Let us now enjoy our code. ConnectonPoolIMPL provides an implementation of ConnectionPool based on a simple policy. PooledConnection encapsulates a database connection to work with ConnectionPool. Perfect? But slow! PooledConnection is just working with ConnectionPoolImpl. Zhang San wants to write ConnectionPool2 to reinforce a Decorator. How can you make different ConnectionPool's implementation to use our PooledConnection? Moreover, in all about twenty entrust functions, we all have if (isclosed ()) .... Is it very familiar? Once a Connection is after being close (), only after Nirvana (returned again by ConnectionPool.getConnection (). And all the calls of closed Connection are the same. (No, no, no!) Guess what is it? Yes, State Pattern!
