Peter Johnson wrote:You don't need a connection pool for that - just have the app establish a connection at the start and then use that same connection every time the app needs to communicate with the database. Then close the connection before the app exits. In effect, this gives you a connection pool of 1 connection.
I have a hunch that the person telling you to use a connection pool is thinking "the app only needs to talk to the database every 5 seconds, so rather than keeping the connection open (during the time the app is not talking to the database), why not use a connection pool?" The only problem with that is that by definition a connection pool establishes N connections to the database and keeps those connections open for the duration of the pool. Yes, you can have the pooling mechanism establish more connection if needed, and close connections no longer needed, keeping the number of connections between an arbitrary min and max connection count, but let's ignore that for this discussion. The key here is that the connections in the pool remain open even when not being used.
So like I said in the prior paragraph, you can easily code a pool of 1 connection. A connection pool that ranges from 0 to 1 connections is also easy: open the connection when you need it and close it afterwards. Come to think of it, that is what your app might be doing already and thus the suggestion to "use a connection pool" might be to prevent this continuous bouncing of the connection. In which case go with the connection pool of 1 connection.
I see wind mills
Rodrigo Bossini wrote:Would I have any problems if I do implement the 1 connection pool and use it in a multithreaded application?