Bug #106648 ResultSet::getDate creates unnecessary stack trace

• Submitted: 6 Mar 2022 8:20
• Modified: 9 Mar 2022 9:52
• Reporter: Jürgen Lind
• Status: Verified
• Category: Connector / J
• Severity: S4 (Feature request)
• OS: Any
• CPU Architecture: Any

[6 Mar 2022 8:20] Jürgen Lind

Description:
We experienced severe performance differences between a standalone Java application that accesses an ResultSet and a Spring application that uses the same code. Upon further investigation, we discovered that the ResultSet implementation of the getDate-Method generates an SQLWarning regardless of whether it is logged or not. Depending on depth of the current stack, there is a huge performance penalty in generating the stack. 

How to repeat:
Use ResultSet::getDate in an application with a low number of stack frames and compare with deeply nested code.

Suggested fix:
Create the stack trace only if it es logged.

[6 Mar 2022 8:21] Jürgen Lind

Changed title to better reflect the problem area

[7 Mar 2022 10:53] MySQL Verification Team

Hi,

What warning do you get?

thanks

[7 Mar 2022 13:00] Jürgen Lind

The warning generated is a ResultSet.PrecisionLostWarning. For me the problem seems to be the fact, that the ResultSetImpl registers iteself as the WarningListener of the SqlDateValueFactory. This triggers the call of the warningEncountered Method of the ResultSet which creates the stackTrace via the super() calls.

[7 Mar 2022 13:16] MySQL Verification Team

Hi,

Weird that getDate produces this warning. Anyhow, I have issues reproducing this, what kind of connection string is your spring app using? Are you using prepared statements (server or client side?)?

If you maybe have a minimal test case I can play with as the quick test I whipped up did not reproduce this

Thanks

[7 Mar 2022 13:31] Jürgen Lind

The testcase where I have encountered the issue is actually quite simple
- in the database, I have a column of type datetime(6)
- I do not use any spring-stuff to get the connection, I'm using the DriverManager directly
- The connection string has no parameters whatsoever
- The method to extract the value from the ResultSet is getDate(String)

If I switch to using getTimestamp, the performance is much, much better.

[9 Mar 2022 9:52] MySQL Verification Team

Thanks

[19 Oct 2023 11:24] Filipe Silva

Hi,

This is not a bug. Connector/J rightfully creates this kind of warnings and at that time it must create an instance of java.sql.SQLWarning, which is an java.lang.Exception so it automatically collects the stack trace of the running thread.

This is also not related to logging because you can get the warnings at any time, with or without logging enabled.

The only alternative I see would be to implement an option that skips producing warnings altogether, but that would be a non-JDBC compliant vendor extension. So, this makes this report a feature request instead of a bug - changing the severity to S4 (Feature request).

Thanks