Bug #14180 | max_allowed_packet set for session ignored (for PreparedStatement) | ||
---|---|---|---|
Submitted: | 20 Oct 2005 13:44 | Modified: | 15 Nov 2005 13:58 |
Reporter: | Gustav Oesgaard | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | Connector / J | Severity: | S3 (Non-critical) |
Version: | 3.1.10 | OS: | Windows (Windows XP) |
Assigned to: | CPU Architecture: | Any |
[20 Oct 2005 13:44]
Gustav Oesgaard
[23 Oct 2005 10:21]
Vasily Kishkin
Could you please say me version of mysql ?
[24 Oct 2005 7:40]
Gustav Oesgaard
Sorry, version of server is "mysql Ver 14.7 Distrib 4.1.12a, for Win32 (ia32)"
[25 Oct 2005 12:23]
Vasily Kishkin
Thanks for the bug report. I was able to reproduce the bug. My test case is attached.
[25 Oct 2005 12:24]
Vasily Kishkin
Test case
Attachment: Bug14180.java (text/java), 1.32 KiB.
[26 Oct 2005 9:17]
Gustav Oesgaard
Great that you were able to reproduce the bug. Do you know any "workaround" for this issue (a way to let me insert the large amount of data without modifying my.ini)?
[15 Nov 2005 13:58]
Mark Matthews
You must use the "sessionVariables=..." to set this session value for max_allowed_packet. These variables are sent before the driver reads the values for itself during connection initialization. You can _not_ issue any "set system_variable" queries from JDBC directly, this is not supported, as the driver reads the max_allowed_packet value _once_ on connection initialization. The server doesn't provide information to tell clients when these values have changed, so there's no efficient way to poll for changes to this value. The driver must enforce max_allowed_packet on the client side, as older versions of the server would clobber the connection with no useful error message when the packet exceeded max_allowed_packet. This can also be considered a denial-of-service attack, as it would keep the server busy reading all kinds of large packets.