-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Return useful error when attempting to reuse a blocked connection #526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
#314 and this is completely different. MySQL protocol is not async. Previous request must be finished before sending next request. |
This should however return a different error than "busy buffer". I'm surprised database/sql even allows this. |
I am not sure whether it depends on the setting of STMT_ATTR_CURSOR_TYPE. In packets.go:915, it is set to CURSOR_TYPE_NO_CURSOR. We also use mysql c driver in other project. It is set to CURSOR_TYPE_READ_ONLY so that more than one resultset can be opened on one connection at the same time. |
http://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-attr-set.html
So you cannot keep old resultset opened even when using STMT_ATTR_CURSOR_TYPE. |
This note just says the open cursor for the stmt to be re-executed will be closed, not cursors for all stmts on the connection, i.e. only one cursor can be opened for one stmt at any time. |
Hmm. You may right. |
I think in many scenarios this feature is needed, such as nest-loop search, ... Another problem is, without no cursor all dataset will be fetched to client-side. Maybe one performance issue when dataset is huge. Hope it can be added in the future version :) |
I don't understand this yet. Could you provide complete example written in C, using MySQL Connector/C? |
Ah, I found the document. It is in "Stored Procedures" section, not "Prepared Statements" section. |
I created issue #1053 regarding cursor support. Please continue the discussion about that over there. The original issue still returns the same confusing error:
With the following adopted test code, which still has to modified to check for the correct error type: func TestIssue526(t *testing.T) {
runTests(t, dsn, func(dbt *DBTest) {
tx, err := dbt.db.Begin()
if err != nil {
dbt.Fatal(err)
}
stmt1, err := tx.Prepare("SELECT 1")
if err != nil {
dbt.Fatal(err)
}
rs1, err := stmt1.Query()
if err != nil {
dbt.Fatal(err)
}
rs1.Next()
err = rs1.Err()
if err != nil {
dbt.Fatal(err)
}
stmt2, err := tx.Prepare("SELECT 2")
if err != nil {
dbt.Fatal(err)
}
rs2, err := stmt2.Query()
if err != nil {
dbt.Fatal(err)
}
rs2.Next()
err = rs2.Err()
if err != nil {
dbt.Fatal(err)
}
})
} |
Issue description
the latest version: 1.3.
Prepare one statement and execute it on one transaction, keep rows open. Error happens when trying to prepare another statement:
[mysql] 2016/12/08 15:45:57 packets.go:431: busy buffer
I see issue#314 which was similiar with the problem and closed. Looks like this problem not fixed in 1.3.
Example code
Error log
Configuration
*Driver version:1.3
Go version: go version go1.7.1 windows/amd64,go version go1.7.4 linux/amd64
The text was updated successfully, but these errors were encountered: