mixing basic DataSource with connection pooling DataSource: when to call close()?

Question

I'm in the process of adding connection pooling to our java app.

The app can work with different rdbmses, and both as a desktop app and as a headless webservice. The basic implementation works fine in desktop mode (rdbms = derby). When running as a webservice (rdbms = mysql), we see that connection pooling is needed to get good concurrent behaviour.

My initial approach was to use dependency injection to decide between a basic DataSource or a connection pooling DataSource at startup time.

The problem in this scenario is that I don't know when to call connection.close(). My understanding is that when using connection pooling, you should close() after each query so the connection object can be recycled. But the current non-pooling implementation tries to hang on to the Connection object as long as possible.

Is there a solution to this problem? Is there a way to recycle a basic connection object? What happens if I don't call connection.close() with a thread pooled connection object?

Or is it simply a bad design to mix these two connection strategies?

Answer 1

If I understand you correctly, essentially you are doing your own pooling implementation by holding on to the connection as long as possible. If this strategy is successful (that is the program is behaving as you describe it), then you have your own pool already. The only thing adding a pool will gain you is to improve the response time when you make a new connection (as you won't really be making one, you will be getting it from the pool), which is apparently not happening all that often.

So, I would cycle back to the assumption underlying this question: Is it in fact the case that your concurrent performance problems are related to database pooling? If you are using transactions in the MySQL and not the Derby, that could be a big cause of concurrency issues, as an example of a different potential cause.

To answer your question directly, use a database pool all the time. They are very little overhead, and of course change the code to release connections quickly (that is, when the request is done, not as long as the user has a screen open, for example) rather than holding on to them forever.