tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit <>
Subject Re: JDBC Pool - Error handling during connection creation
Date Thu, 08 Mar 2012 16:55:26 GMT

On 08-Mar-2012, at 6:37 PM, Daniel Mikusa <> wrote:

> On Thu, 2012-03-08 at 00:34 -0800, amit shah wrote:
>> Comment below
>> On Wed, Mar 7, 2012 at 8:53 PM, Christopher Schultz <
>>> wrote:
>>> Hash: SHA1
>>> Amit,
>>> On 3/7/12 12:12 AM, amit shah wrote:
>>>> I am using tomcat-jdbc.jar and tomcat-juli.jar from version
>>>> 7.0.26.
>>>>> I don't see any place in setupConnection where an exception is
>>>>> swallowed, do you?
>>>> Have a look at the public boolean validate(int
>>>> validateAction,String sql) method in PooledConnection class line no
>>>> - 445.
>>>> The validate method ignores any exception which is thrown while
>>>> validating the connection or executing the initSQL query.
>>> If you have debug logging enabled, it will log the exception. So,
>>> enable debug logging and try again. *shrug*
>>>> The createConnection() method in ConnectionPool class which calls
>>>> the validate() method returns null in such a case and hence it
>>>> leads to a null pointer exception in setupConnection method.
>>>> Ignoring the exception in the validate() method may sound
>>>> appropriate (not sure for what reason though) but my point is that
>>>> it makes troubleshooting the issue a lot harder.
>>> Just turn on debug logging and you'll see the original exception. I
>>> think in this case, the error is quite fatal so checking for null and
>>> emitting some other error message would only be slightly more helpful
>>> to you, but the effect would be the same.
>> I understand that turning the log level to debug will display the original
>> exception. The point is in production environments the log level would be
>> by default info and it would take a longer time to understand the root
>> cause.
> Why not just set the log level to debug for that particular class?  The
> logging in that class seems to be minimal, even at debug level.

Enabling debug level would add some extra handling

1. We use slf4j & logback as our logging framework & tomcat uses jul logging. We would
have to add jul-to-slf4j.jar to direct the jul messages to logback. This adds a performance
overhead since the validation code & this class would be executed frequently.

2. Specially adding a logger in logback.xml for this particular class. We have multiple web
applications which do not share the logback.xml currently.

If the exception is not ignored and thrown right where it occurred, the stack trace would
be enough to understand the root cause of the issue. 

>> In our case, we execute a SP as an initSQL query, so the reasons why the
>> query fails would increase. Hence it would been easier if the validate()
>> method throws the exception instead of ignoring it.
> I understand that you would like to get access to the exception, but can
> you explain why you would want to do this?  What would you do with the
> exception?  Where would you handle the exception?

I do not want to handle the exception. It would just help in understanding the root cause
in secs instead of mins since there could many reasons why establishing a connection could
fail. Seeing a null pointer exception does not help at all.

I would appreciate if someone could detail on the benefits on having the code the way it is
currently implemented i.e. why the exception is ignored instead of just throwing it there
right away?

> Dan
>> Do you see any issues in throwing the exception right there?
>>> - -chris
>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>>> Comment: GPGTools -
>>> Comment: Using GnuPG with Mozilla -
>>> VkoAoL6g5gMTaYpnHvj7HZDqWT6P+qcE
>>> =AzPZ
>>> -----END PGP SIGNATURE-----
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message