Just something we noticed as we were thinking of ways to simulate a form
of nested (BEGIN/COMMIT/ROLLBACK) transactions via the connection
object. We were looking for a way to detect that you were inside an
explicit (not auto commit) transaction (but autocommit==0 is not a proxy
for this).
It does seem safer/easier to grab the status from mysql rather than
modeling it. Might be a performance hit depending on how often it is
used (then again a cached copy should only need an update after certain
api fn's) It's not a bad idea to prevent people from setting the
setting outside the blessed method if that's the case (and this further
limit the places you need to update the cached value).
By the way, given that there is no Connection.startTransaction(), I
assume we're OK issuing that via a statement?
Mark Matthews wrote:
The JDBC spec states that you should change autocommit via
Connection.setAutocommit() (Section 9.3). Many other APIs, besides JDBC
depend on this behavior for transaction control. Is there a reason
you're not using the connection methods to change it?
I've actually seen other JDBC drivers for other databases that will
throw a SQLException if you try and change the autoCommit value outside
of the 'normal' means.
-Mark
- --
4 messages in com.mysql.lists.bugsRe: Connector/J incorrectly models au...