| Bug #35073 | 'Connection must be valid and open' - pooling issue | ||
|---|---|---|---|
| Submitted: | 5 Mar 2008 11:03 | Modified: | 6 Mar 2008 10:34 |
| Reporter: | Jeremy Morton | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / NET | Severity: | S2 (Serious) |
| Version: | 5.2.0 | OS: | Windows |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Connection, connector, open, pool, pooling, valid | ||
[6 Mar 2008 10:34]
Jeremy Morton
We think we've figured out the bug, and it isn't in mySQL connector (we were using a static variable to hold the MySQLconnection that was being shared between threads, causing chaos.)
[6 Mar 2008 10:51]
Tonci Grgin
Jeremy, thanks for your report and for following up on it. Others my benefit from your findings. Using a variable that way usually leads to trouble on any framework, not only .NET. Even though it's closed, I'll be monitoring this report in case new info is provided. Thanks for your interest in MySQL.
Description: Our web application opens a connection, via the .net connector, to the mySQL database for every web request, and encloses all mysqlconnection.open executions in a try ... finally block, where we do a .close in the finally block. We seems to be getting weird concurrency issues when we set pooling=true in the mySQL connection string, none of which happen with pooling=false. Once such error that crops up (an exception is thrown) is "Connection must be valid and open". Another is that when we're trying to execute a non-query, we get: "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host." I can only guess this is some kind of threading issue; it appears connections are getting closed before threads try to execute queries, even though that thread hasn't closed the connection itself. It seems like a bug in the connector's pooling code, perhaps? How to repeat: Create a Visual Studio web application where each request opens a mySQL connection via the .net connector on each request in the Application_PreRequestHandlerExecute event, enclosing each connection's .open call in a try{} block, followed by a finally{} block containing a .close call for that connection. Construct a webpage with many images on that will cause concurrent web requests to be sent to that application, and this bug should crop up somewhat unpredictably. pooling=true must be set in the connection string.