After my connection pool expires, when I try to open more connections in parallel than my max number of allowed connections in the pool, then I start getting timeout exceptions when trying to obtain a connection from the pool.
That is expected, however, the pool seems to be left in that state, where everything else I do since that moment gets the same timeout exceptions. As if each of the connections in the pool had been left busy, and can't be reused. I would expect the connections to get freed up over time, and then other connections being allowed, but this is not happening.
I'm using Play 1.2.5 with a jdbc driver to mysql, and from the logs I reckon the pool is C3P0.
I'm not explicitly closing the connections, since I believe is the right thing to do when using a pool, but I'm not 100% sure.
I don't know if this could be a connection leak in one of the framework/libraries I'm using, or if I'm doing something wrong or not doing something I should.
When I catch one of the timeout exceptions, what is the right thing to do?
You must explicitly close connections when you use a connection pool. A connection pool has a collection of physical connections to a database. When you request a connection from the pool, it marks that physical connection as in-use and hands you a logical handle to that connection. This logical handle essentially is a wrapper or proxy which forwards most method calls (either directly or with some modification) to the physical connection.
When you call close() on this logical handle, the connection pool gets a signal that the physical connection is available again (that is: can be returned to the pool), the logical handle will from then on behave as a closed connection, but the actual physical connection is still open. If you don't call close(), the connection pool never gets this signal so the physical connection will remain in-use and won't be available for re-use.
Some advanced pool configurations allows the pool to detect this situation (eg using a timeout, or maybe with finalizers etc) and reclaim the connection, but you should not depend on that.
TL;DR: Always call close() on your connection when you are done with it, whether it comes from a connection pool, a non-pooled DataSource or DriverManager.
Related
How safe is connection pooling with regard to connection settings? When a connection is released back to the pool, does the pool issue some sort of reset command to restore the connection to a known state, or is the connection just naively returned to the pool?
This is something that always bothers me when writing code that uses SET FOREIGN_KEY_CHECKS=0. If I forget/fail to call SET FOREIGN_KEY_CHECKS=1 before releasing the connection back to the pool, does the next process end up with an unsafe connection with foreign key checks disabled?
Since this may be specific to the pooling software, I'm mainly asking about node-mysql and JDBC. I looked at the code for node-mysql and couldn't see anything that resets the connection. I have no idea about JDBC.
what if we set minimum poll size to zero?
And, what will be a default minimum pool size ?
Here's the MySQL documentation on connection pooling, this is what it says:
Most applications only need a thread to have access to a connection
when they are actively processing a transaction, which often takes
only milliseconds to complete. When not processing a transaction, the
connection sits idle. Connection pooling enables the idle connection
to be used by some other thread to do useful work.
In your case, if you have 4 connection strings and they all are different (meaning they are connecting to different database server and/or database) then it's safe to say that your application will have at least 4 connections in pool.
With the node-mysql module, there are two connection options - a single connection and a connection pool. What is the best way to set up a connection to a MySQL database, using a single global connection for all requests, or creating a pool of connections and taking one from the pool for each request? Or is there a better way to do this? Will I run in to problems using just a single shared connection for all requests?
Maintaining a single connection for the whole app might be a little bit tricky.
Normally, You want to open a connection to your mysql instance, and wait for it to be established.
From this point you can start using the database (maybe start a HTTP(S) server, process the requests and query the database as needed.)
The problem is when the connection gets destroyed (ex. due to a network error).
Since you're using one connection for the whole application, you must reconnect to MySQL and somehow queue all queries while the connection is being established. It's relatively hard to implement such functionality properly.
node-mysql has a built-in pooler. A pooler, creates a few connections and keeps them in a pool. Whenever you want to close a connection obtained from the pool, the pooler returns it to the pool instead of actually closing it. Connections on the pool can be reused on next open calls.
IMO using a connection pool, is obviously simpler and shouldn't affect the performance much.
I'm a little confused around connection pools. I'm using Hibernate on top of a MySQL database. Hibernate's connection pool strategy is determined by c3p0.
What's the relationship between Hibernate's connection pool size vs MySQL's?
My code running Hibernate can be scaled to multiple instances on AWS (so n # of instances each with Hibernate connection pool size of m). All instances however talk to a single RDS MySQL instance, which itself has a connection pool size q.
Does this mean if there are n*m active connections and n*m>q, there will be connections that will have to wait in MySQL's queue?
Thanks!
Your question asks about "Hibernate's connection pool size vs MySQL's". The important distinction to keep in mind is:
A connection pool is an application concept, not a database one. The connection pool used by your application (i.e., Hibernate) is simply a way of speeding up the communication to the database. Since establishing each connection is relatively slow, it's more efficient to pre-establish a bunch of connections and then let your application use them as needed.
On the other hand, a database doesn't pool connections. Instead, it allows clients to establish connections upon request up to a max limit (e.g., the max_connections parameter in MySQL). If a client asks for a connection and the database has already hit the max limit, then a connection error will occur.
So to answer your question, if you configure your application connection pools to try to pre-establish more connections than the database will allow, you will get a "Too many connections" error from MySQL. This could be avoided by either raising the MySQL configuration parameter or by adjusting your c3p0 max pool size per instance.
In order to avoid the overhead of establishing a new connection each time a query needs fired against MySQL, there are two options available:
Persistent connections, whereby a new connection is requested a check is made to see if an 'identical' connection is already open and if so use it.
Connection pooling, whereby the client maintains a pool of connections, so that each thread that needs to use a connection will check out one from the pool and return it back to the pool when done.
So, if I have a multi-threaded server application expected to handle thousands of requests per second, and each thread needs to fire a query against the database, then what is a better option?
From my understanding, With persistent connections, all the threads in my application will try and use the same persistent connection to the database because they all are using identical connections. So it is one connection shared across multiple application threads - as a result the requests will block on the database side soon.
If I use a connection pooling mechanism, I will have all application threads share a pool of connections. So there is less possibility of a blocking request. However, with connection pooling, should an application thread wait to acquire a connection from the pool or should it send a request on the connections in the pool anyway in a round-robin manner, and let the queuing if any, happen on the database?
Having persistent connections does not imply that all threads use the same connection. It just "says" that you keep the connection open (in contradiction to open a connection each time you need one). Opening a connection is an expensive operation, so - in general - you try to avoid opening connections more often than necessary.
This is the reason why multithreaded applications often use connection pools. The pool takes care of opening and closing connections and every thread that needs a connection requests one from the pool. It is important to take care that the thread returns the connection as soon as possible to the pool, so that another thread can use it.
If your application has only a few long running threads that need connections you can also open a connection for each thread and keep this open.
Using just one connection (as you described it) is equal to a connection pool with the maximum size one. This will be sooner or later your bottleneck as all threads will have to wait for the connection. This could be an option to serialize the database operations (perform them in a certain order), although there are better options to ensure serialisation.
Update: The newer X Protocol supports asynchronous connections, and newer drivers like Node's can utilize this.
Regarding your question about should the application server wait for a connection, the answer is yes.
MySQL connections are blocking. When you issue a request from MySQL server over a connection, the connection will wait, idle, until a response is received from the server.
There is no way to send two requests on the same connection and see which returns first. You can only send one request at a time.
So, generally, a single thread in a connection pool consists of one client side connection (in your case, the application server is the client) and one server side connection (database).
Your application should wait for an available connection thread from the pool, allowing the pool to grow when it's needed, and to shrink back to your default number of threads, when it's less busy.