was wondering if there is a way to monitor the JDBC connectivity via a java application ?? our app connects to a db via JDBC and sometimes the connection takes too long / hangs. have looked at the database but i think its JDBC which is causing problems.
is there a way to monitor the connection such that the app sends an email whenever the connection "stalls" or goes down ??
It should not occur as a norm. You should use some profiler to figure out where the problem lies. Regarding emailing the error/exception, you can set up email thingie as a part of your exception handling mechanism.
I am challenging this. Chances are that the JDBC library is the most reliable and best tested part of your application. Millions of people are using it. I think that it is something else which is causing problems.
(maybe resource issues on your server? Do you have enough memory on the server? Do you have enough connections available - maybe all connections are currently consumed, and your application waits until someone else returns a connection?)
jamon offers a jdbc proxy driver that wraps the underlying driver and keep stats for connections, each SQL query, exceptions and more. It can also track which queries are currently running, and the N most recent queries as well as the slowest queries in the past day, week, etc. No code changes are required as it is all done with the driver.
As an added bonus you can also monitor page hits, ejb calls, and log4j calls in the same way without changing your code.
Before going through a lot of trouble diagnosing, have you handled the common cases?
1. For one, are you sure you're not hitting some sort of connection limit?
a. What sort of connection are you getting? Are you creating a vanilla JDBC connection, or are you getting one via a connection pool?
b. How many connections is the pool allowed to grow to?
c. How many connections will the DB server actually allow?
d. Regarding JDBC connections, are you closing the connection each time you're done?
#a to #b should be easy to diagnose via the app server, if you're using one.
#c should be answerable by the DB admin (or trial & error if you don't mind an angry admin )
#d requires a bit of code look-through.
2. Perhaps not so likely, any chance you're running into some sort of networking issue or proxy/firewall issues? This has happened to me a few times, in a clustered scenrio when we create a new secondary box.
Joined: May 25, 2008
thanks for the reply everyone, given me a lot to think about.