What is "used jdbc connections"?
2,605 views
Skip to first unread message
Colin
Sep 8, 2011, 1:55:30 PM9/8/11
to javamelody
Hello,
What is the meaning of "used jdbc connections"? This value is
steadily increasing on my Tomcat web app (now nearly 3k) and I would
like to know if this indicates some kind of connection or resource
leak.
"Active jdbc connections" is very low and what I would expect, since
the application currently has very few users.
App server is Tomcat 6.0.29. Connection pool is the new Tomcat jdbc
pool 1.1.0.1 (not the standard one that comes with Tomcat 6.x).
Thank you,
Colin
What is the meaning of "used jdbc connections"? This value is
steadily increasing on my Tomcat web app (now nearly 3k) and I would
like to know if this indicates some kind of connection or resource
leak.
"Active jdbc connections" is very low and what I would expect, since
the application currently has very few users.
App server is Tomcat 6.0.29. Connection pool is the new Tomcat jdbc
pool 1.1.0.1 (not the standard one that comes with Tomcat 6.x).
Thank you,
Colin
David Karlsen
Sep 12, 2011, 5:00:42 PM9/12/11
to javam...@googlegroups.com
Can somebody answer this? I wonder too.
Emeric Vernat
Sep 13, 2011, 12:24:14 PM9/13/11
to javam...@googlegroups.com
Hi,
The online help says that the number of "used jdbc connections" is the number of opened sql transactions; and that in the case where there is no datasource, it is in fact the number of opened jdbc connections in the connection pool.
And it also says that the number of "active jdbc connections" is the number of current sql requests.
In general, jdbc connections come from a jdbc datasource. The jdbc datasource is configured in your application server and is available in JNDI. In your application, you get the datasource instance with a JNDI lookup.
When you want to use a jdbc connection for a transaction, you call "dataSource.getConnection()" to get the connection and then you call "connection.close()" on this jdbc connection at the end of the transaction (after commit or rollback of course). In fact, the "connection.close()" method does not close the socket to the database, it just says that the connection is released by the application to be kept opened in the connection pool inside the datasource (and later, the connection can be reused for another transaction).
Note: Often the "dataSource.getConnection()" and the "connection.close()" methods are not called directly by your application but they are called by some framework such as JavaEE, Spring or Hibernate.
It may happen that your jdbc datasource is not configured in your application and is not in JNDI, but that it is configured in Spring for example, in which case only the lookup is different.
The javamelody UserGuide says how to monitor the jdbc connections for this datasource in both cases.
When you use a jdbc datasource and if it is correctly monitored, the "used jdbc connections" value in javamelody is the number of connections for which the getConnection() method has been called and the close() method has not yet been called.
The "used jdbc connections" is supposed to be between 0 and the max of jdbc connections as configured in the datasource ("maxActive" in the standard Tomcat datasource, "max-pool-size" in the Glassfish connection pool)
And the number of "active jdbc connections" is the number of connections for which an executeXxx method has been called on a statement of the connections and that executeXxx has not yet ended.
The current number of "active jdbc connections" is supposed to be between 0 and the current number of "used jdbc connections".
Finally and I do not recommend that, some applications don't use a datasource from JNDI and neither a datasource from Spring, in which case there is often a connection pool configured directly in the application. And so the close() method is not called at the end of each transaction because connections are kept opened by the application inside its connection pool.
And as said in the online help, when there is no datasource, "used jdbc connections" is in fact the number of opened jdbc connections in this connection pool.
The javamelody UserGuide says how to configure the jdbc driver in order to monitor jdbc connections in this case.
So if the "used jdbc connections" has an increase in your application, it may mean that:
- the javamelody monitoring for jdbc is not well configured in your application
- or your current jdbc setup is not supported by javamelody or javamelody has a bug
- or perhaps your application has a resource leak
Anyway, 3000 jdbc connections seems way too much to me.
I suggest to do a quick check from the database point of view, and to ask the database with a native client how many connections are opened (by all computers).
If oracle, execute "select * from v$session"
If H2, execute "select * from information_schema.sessions"
If mysql, execute "show full processlist"
etc
bye,
Emeric
The online help says that the number of "used jdbc connections" is the number of opened sql transactions; and that in the case where there is no datasource, it is in fact the number of opened jdbc connections in the connection pool.
And it also says that the number of "active jdbc connections" is the number of current sql requests.
In general, jdbc connections come from a jdbc datasource. The jdbc datasource is configured in your application server and is available in JNDI. In your application, you get the datasource instance with a JNDI lookup.
When you want to use a jdbc connection for a transaction, you call "dataSource.getConnection()" to get the connection and then you call "connection.close()" on this jdbc connection at the end of the transaction (after commit or rollback of course). In fact, the "connection.close()" method does not close the socket to the database, it just says that the connection is released by the application to be kept opened in the connection pool inside the datasource (and later, the connection can be reused for another transaction).
Note: Often the "dataSource.getConnection()" and the "connection.close()" methods are not called directly by your application but they are called by some framework such as JavaEE, Spring or Hibernate.
It may happen that your jdbc datasource is not configured in your application and is not in JNDI, but that it is configured in Spring for example, in which case only the lookup is different.
The javamelody UserGuide says how to monitor the jdbc connections for this datasource in both cases.
When you use a jdbc datasource and if it is correctly monitored, the "used jdbc connections" value in javamelody is the number of connections for which the getConnection() method has been called and the close() method has not yet been called.
The "used jdbc connections" is supposed to be between 0 and the max of jdbc connections as configured in the datasource ("maxActive" in the standard Tomcat datasource, "max-pool-size" in the Glassfish connection pool)
And the number of "active jdbc connections" is the number of connections for which an executeXxx method has been called on a statement of the connections and that executeXxx has not yet ended.
The current number of "active jdbc connections" is supposed to be between 0 and the current number of "used jdbc connections".
Finally and I do not recommend that, some applications don't use a datasource from JNDI and neither a datasource from Spring, in which case there is often a connection pool configured directly in the application. And so the close() method is not called at the end of each transaction because connections are kept opened by the application inside its connection pool.
And as said in the online help, when there is no datasource, "used jdbc connections" is in fact the number of opened jdbc connections in this connection pool.
The javamelody UserGuide says how to configure the jdbc driver in order to monitor jdbc connections in this case.
So if the "used jdbc connections" has an increase in your application, it may mean that:
- the javamelody monitoring for jdbc is not well configured in your application
- or your current jdbc setup is not supported by javamelody or javamelody has a bug
- or perhaps your application has a resource leak
Anyway, 3000 jdbc connections seems way too much to me.
I suggest to do a quick check from the database point of view, and to ask the database with a native client how many connections are opened (by all computers).
If oracle, execute "select * from v$session"
If H2, execute "select * from information_schema.sessions"
If mysql, execute "show full processlist"
etc
bye,
Emeric
Reply all
Reply to author
Forward
0 new messages