8 messages in com.mysql.lists.javaRe: UNLOCK TABLES and connection pooling| From | Sent On | Attachments |
|---|---|---|
| Michael McTernan | 24 Feb 2004 09:48 | |
| Sao Many | 24 Feb 2004 19:24 | |
| Marc Slemko | 24 Feb 2004 19:36 | |
| Mark Matthews | 25 Feb 2004 00:07 | |
| Marc Slemko | 25 Feb 2004 00:29 | |
| Mark Matthews | 25 Feb 2004 00:42 | |
| Michael McTernan | 25 Feb 2004 02:55 | |
| Michael McTernan | 25 Feb 2004 02:58 |
| Subject: | Re: UNLOCK TABLES and connection pooling |
|---|---|
| From: | Marc Slemko (mar...@znep.com) |
| Date: | 02/25/2004 12:29:55 AM |
| List: | com.mysql.lists.java |
On Wed, 25 Feb 2004, Mark Matthews wrote:
Marc Slemko wrote:
There are other per connection options that may not be properly reset as well, like transaction isolation level.
I wish mysql had some "reset connection state" call. It isn't clear if that would actually provide any performance boost over closing the connection and reopening it though, ie. not using connection pooling. Connections are fairly lightweight in mysql to begin with.
Marc,
MySQL _does_ have a reset connection state call which will delete temporary tables, reset session variables, etc., and it is supported in Connector/J 3.1.x when you are using MysqlConnectionPoolDataSource as the data source that 'backs' your connection pool.
Sweet! Thanks for pointing it out.
For others interested, it appears it is supported with server version 4.0.6 or higher, is implemented via changeUser() which just reauthenticates to the server, and probably wouldn't be too hard to retrofit into a local change to 3.0.x if required.
BTW, at first glance I'm not thrilled that MyslIO.changeUser() catches Exception and throws a new RuntimeException()... doesn't seem to fit in with exception handling in the rest of the code, and is misleading since the method claims to throw SQLException but... doesn't, so it makes properly handling error conditions hard.