Skip to content
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

Can't create more than max_prepared_stmt_count statements (current value: 16382) #86

Open
ablegao opened this issue Sep 29, 2013 · 3 comments

Comments

@ablegao
Copy link

ablegao commented Sep 29, 2013

this my code .
http://play.golang.org/p/3q18mG9mbJ

so , https://github.com/go-sql-driver/mysql/blob/master/statement.go have stmt.Close(). how to use it in mymysql?

@ablegao
Copy link
Author

ablegao commented Sep 29, 2013

stmt, err := db.Prepare("update user set alias='abc111' where Username=?")
stmt.Raw.Delete()

.........

@ziutek
Copy link
Owner

ziutek commented Sep 30, 2013

autorc is intended for long life processes that create some server side statements at start and use them for different data for whole life of process. There is conceptually problem with close a connection, or destroy statement because such operation can return an error (especially a network error).

autorc is intended to recover from errors by reconnect and recreate all previously created statements. But in this case (close connection, delete a statement) it shouldn't do this. So autorc.Conn.Close and autorc.Stmt.Delete will have inconsistent behavior with other functions. I didn't found any proper solution for this problem and it turned out that these functions aren't necessary in all my real applications. So they haven't be implemented but Raw field is there so you can call Delete and Close yourself and because it is special case you should handle all errors yourself and probably invalidate Conn/Stmt (by set Raw = nil) if you didn't plan to use it in feature (if you don't invalidate them, they probably can be recreated at second use).

@mattbucci
Copy link

@ziutek Just came across this issue today, is this still the recommended solution 2 years later?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants