5 messages in com.mysql.lists.javaRe: Is ConnectorJ 5.0 production ready?| From | Sent On | Attachments |
|---|---|---|
| Eric Raymond | 01 Sep 2006 11:19 | |
| Mark Matthews | 01 Sep 2006 12:22 | |
| Eric Raymond | 04 Sep 2006 09:24 | |
| Mark Matthews | 07 Sep 2006 06:25 | |
| wolverine my | 21 Sep 2006 00:09 |
| Subject: | Re: Is ConnectorJ 5.0 production ready? |
|---|---|
| From: | Mark Matthews (ma...@mysql.com) |
| Date: | 09/07/2006 06:25:23 AM |
| List: | com.mysql.lists.java |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Raymond wrote:
http://www.mysql.com/products/connector/j/ still refers to 3.1 as the production ready version.
So there are no rough edges in 5.0 which you would worry about?
Eric,
The only major thing that is totally new in 5.0 is XA support. Everything else is an "evolution" of what was in 3.1. Major changes surround some cleanup of synchronization, but if you're not sharing JDBC connections, statements, etc. across multiple threads you shouldn't notice anything different (and if you are, it should actually work better).
What happens when setTimeout() throws an exception ... and the last statement you executed was a commit? Seems like that could be "interesting"? (I have no evidence to suggest there's an issue, but it looks like the connector handles this with a timer on the connector side ... rather than the server side ... which seems risky.)
Since according to the JDBC specification you're not supposed to issue Statement.execute("commit"), this should never happen. (This is actually clarified in the JDBC-4.0 specification, with wording along the lines of "If a method exists on a JDBC interface for changing session configuration, or transaction semantics, you are not allowed to issue these types of statements outside of these methods". Otherwise, JDBC drivers would need to parse nearly every query to determine if you're doing things that change the state of the connection "behind their back".
In any case, nearly every vendor I've talked to implements statement timeouts on the client side, as the functionality needs to cover the case where the server has gone away, but the network hasn't noticed yet. If you leave things at defaults, you might have a connection that's blocked for upwards of 10 minutes in some network failure scenarios.
-Mark
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFAB3atvXNTca6JD8RAqkMAKC15SF5bkhtQYpTOkOJrt3N62x4zgCfd/d5 iiiqdtdjD9Gnu6zr2Z0jYmk= =CMjv -----END PGP SIGNATURE-----