I'm going to assume your requirement to not use container or database features has a good reason behind it. I'd prefer well tested and supported code from those vendors over the risks of writing my own. But ...
Pooling any one thing can be a lot like pooling any other. We made a socket connection pool from a blocking queue. At startup put some number of connections in the queue. When you need one get from the queue; when finished put it back in the queue. If the queue is empty, the thread blocks until some other thread puts a connection back in. The client code must be coded to use get & put instead of open & close.
Or, pooling connections can be completely different. I've seen a pool that implemented some of the interfaces you use to get, open and close connections. It maintained a pool completely hidden from the client users. Far more complex internally, but fairly transparent to plug into an existing app.
Either way, there are lots of options about high and low water marks and what to do when you hit them.
Any of that sound interesting?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by aakash bhatt: I had to write a code for ConnectionPooling.
I really don't think there's space in this world for even one more connection pool. Writing a slapdash "me-too" connection pool is easy, but writing a good one is surprisingly hard. How did you eliminate all existing free connection pool implementations such as the Commons DBCP?
If you insist on writing your own and you do want to do a decent job, start by reading up on ConnectionPoolDataSource and PooledConnection. Contrary to popular belief, these do not implement a connection pool but are infrastructure for connection pool implementations. The JDBC 3.0 API Tutorial and Reference by Fisher et al contains a very useful discussion (prejudice warning: I was one of the tech reviewers for this book).
- Peter [ August 30, 2004: Message edited by: Peter den Haan ]
Peter den Haan
Joined: Apr 20, 2000
Originally posted by Stan James: Or, pooling connections can be completely different. I've seen a pool that implemented some of the interfaces you use to get, open and close connections. It maintained a pool completely hidden from the client users.
Surely in this day and age you wouldn't implement it any other way? I mean, the connection pool behind the DataSource you get from every second-rate application server works that way. The last thing you want is some oddball connection pool API intruding on application code with explicit returning of connections to the pool and so on; that's how they used to work in the dark old days. There's no excuse for that anymore.