tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport
Date Wed, 08 May 2013 17:40:38 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nick,

On 5/8/13 1:34 PM, Nick Williams wrote:
> 
> On May 8, 2013, at 12:08 PM, Michael-O wrote:
> 
>> Am 2013-05-08 14:38, schrieb Christopher Schultz:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>> 
>>> Nick,
>>> 
>>> On 5/8/13 8:08 AM, Nick Williams wrote:
>>>> 
>>>> On May 8, 2013, at 6:54 AM, Christopher Schultz wrote:
>>>> 
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>> 
>>>>> Michael,
>>>>> 
>>>>> On 5/8/13 3:01 AM, Michael-O wrote:
>>>>>> I recently have started using the SlowQueryReport to
>>>>>> tackle performance issues. The log message,
>>>>>> unfortunately, does not contain the parameters passed to
>>>>>> the prepared statements. Though AbstractQueryReport
>>>>>> receives this information in
>>>>>> 
>>>>>> protected String report*Query(String query, Object[]
>>>>>> args, final String name, long start, long delta)
>>>>>> 
>>>>>> but ignores this information. The report would highly
>>>>>> benefit from. E.g., Commons DBUtils prints out the query
>>>>>> and the parameters in the case of an exception. The sole
>>>>>> query isn't really helpful.
>>>>>> 
>>>>>> Can we add this?
>>>>> 
>>>>> Sure.
>>>>> 
>>>>>> Should I file a ticket?
>>>>> 
>>>>> Yes. A BZ issue with a patch is likely to get done a whole
>>>>> lot faster than one without a patch (plus you get credit
>>>>> for your contribution).
>>>>> 
>>>>> - -chris
>>>> 
>>>> There needs to be an option to disable logging query
>>>> parameters somehow. Query parameters are sometimes sensitive,
>>>> and in some environments (medical, legal, etc.) logging them
>>>> might even be in violation of the law.
>>> 
>>> +1
>>> 
>>> If you really want to get cute, allow the user to specify named
>>> query parameters that should never be displayed "e.g.
>>> 'password'", though this is a) perhaps not possible and b) not
>>> reliable because you can bind parameters by position as well as
>>> by name.
>> 
>> Java has no support for named parameters. How is that supposed to
>> work?
> 
> Agreed that it the setting won't be effective if they don't use
> prepared statements. Therefore, the setting name should reflect
> this restriction.
> 
> I'm not sure what Chris is referring to. You are right, Java has no
> support for named parameters, even in Java 8. Chris might be
> thinking of Hibernate or Spring's JdbcTemplate, which permit using
> named parameters. Ultimately, these get converted to indexed
> parameters before the query is actually executed.

I'm talking about java.sql.ResultSet.updateFoo(String columnName, Foo
fooData)

Or are all your queries SELECTs?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRio4WAAoJEBzwKT+lPKRY3MsP/3CaNjAgFlEU0kOQX0cpGBQC
LF4+Mq4oGwtB8YOOzr/P6mCSaQC/x2SNoOZiBWv4ZNEw8F82UuEKEW+/UetR9rPL
eumv7g8W6kWxM9v4/GQlF93Onw7qNtGw/eA9j/MyTebCUxQR9Uil+qY1UGZSJGPq
LD1BaGN8Fc12bsYB/WYqCHIThC3zoI+ixley+fTVF0Dc3vc4atgkjmBZmMxE+Rqi
WD66fQuIPOXoM2lBN5Z4motg/vBwcl/0CZs5bAiNSDfXbhMjgN5TRdYESI4eKjCw
bR1/rTRV2uix0UXOJWYW5H9mbccqkdcUs3GHGb9picTUehsmvPP5XCXbdBekiRZE
pbsKeUB/Fx0CDM8yID0jqZdSRe+EHq3PlvbJvvzDWuvGH3ND7ZfwwAkz4kNy4xIK
xwvXDGbjgtThHIfszmaP3K+vdbaTHpX72ejIRspiY4R8zlB4hpl/vNq+lJEZGApH
1PCFyB6SNlKxnl3ssMqSDXEbBcTGF1KFQAiFLzjXzL5KZDwCzmoWloyJp0ZCTL8t
nNhCgicZsGb4NV/0CIDgj2GhHegfwykFkKyawSKZ8jJtvi07FnCHvRwyTjqYJRfR
fORpk45iVmEXnB9W1YWxb8xRlkpzwIo6aVUpNTPazrNawz00yUhbmsUQ54v5tson
utTyDNO+0DXQ6zsWFFu4
=wBws
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message