Bug #77421 | Connection Properties don't appear to reset due to pooling | ||
---|---|---|---|
Submitted: | 21 Jun 2015 0:29 | Modified: | 4 Apr 2016 22:25 |
Reporter: | Zackary Geers | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | Connector / NET | Severity: | S3 (Non-critical) |
Version: | 6.9.6.0 | OS: | Windows |
Assigned to: | CPU Architecture: | Any |
[21 Jun 2015 0:29]
Zackary Geers
[21 Jun 2015 0:47]
Zackary Geers
Expected behavior: Setting a connection-bound property shouldn't affect future connections. Actual behavior: Setting a connection-bound property affected a future connection.
[21 Jun 2015 0:57]
Zackary Geers
select version() returns 5.6.22-log
[22 Jun 2015 9:28]
Chiranjeevi Battula
Hello Zackary Geers, Thank you for the bug report. Verified this behavior on Console Application in Visual Studio 2013 (C#.Net) with MySQL Connector/Net 6.9.6. Thanks, Chiranjeevi.
[22 Jun 2015 9:29]
Chiranjeevi Battula
test results
Attachment: 77421.txt (text/plain), 6.27 KiB.
[4 Apr 2016 21:11]
Bradley Grainger
This appears to be by design in the MySQL connector, according to the connection string documentation about connection pooling: https://dev.mysql.com/doc/connector-net/en/connector-net-connection-options.html#idm139937... You should be able to work around the bug by explicitly specifying "ConnectionReset=false" when creating the connection string.
[4 Apr 2016 21:12]
Bradley Grainger
Sorry; typo in last comment. I meant "ConnectionReset=true". ("ConnectionReset=false" reproduces the bug.)
[4 Apr 2016 22:13]
Zackary Geers
I will switch my connection string setting. Perhaps the default should be changed? I would not expect state to be carried over between different Connection objects. If you pull an entry out of the connection pool, you don't know what state it is in, it could be in any state, so you need to reset it. Resetting the connection settings each time an connection is pulled out of the pool is automatically done in System.Data.SqlClient, so this is unlike how the other .Net data providers handle connection pooling.
[4 Apr 2016 22:25]
Zackary Geers
Also, tracing down bugs caused by this issue are very tricky, another reason I think the default should be to reset between connections. The issue I found was because one thread set the AutoCommit to 0, while the rest of the application used the default of autocommit to 1, in a multi-threaded app. Some of the data wasn't getting updated in the database, and it took me a long time to figure out that it was set to autocommit 0, and longer to figure out that the pooling by default carries state over.