[ http://jira.jboss.com/jira/browse/JBJCA-16?page=comments#action_12314911 ] Adrian Brock commented on JBJCA-16: -----------------------------------
Correct. JBoss takes advantage of an obvious (though undocmented) performance optimization done by all databases. connection.setAutoCommit(false); // do work connection.commit(); // ends the previous transaction // We should do the following, but that would typically involve // two network requests for crappy jdbc drivers connection.setAutoCommit(true); connection.setAutoCommit(false); // But we actually do // *nothing* // Followed by the next transaction // do work connection.commit(); Databases don't automatically start a new/next transaction after a connection.commit() because this would be a waste if the user is just going to do connection.close() straight away. They start the next transaction at the first "do work". In fact, JBoss's jdbc wrapper uses the same technique (for the same reason) with the checkTransaction() done during createStatement(), etc. It would agree that the checkState() is better placed before the setAutoCommit(false), but this wouldn't fix your problem. > Changing readonly after autocommitt set to false fails with C-JDBC Driver > ------------------------------------------------------------------------- > > Key: JBJCA-16 > URL: http://jira.jboss.com/jira/browse/JBJCA-16 > Project: JBoss JCA > Type: Bug > Versions: JBossAS-4.0.1 > Reporter: youngm > Assignee: Adrian Brock > > > In the C-JDBC JDBC Connection driver it uses autoCommit=false to determine if > it is in a transaction when changing readOnly. > Unfortunatly LocalManagedConnection sets autoCommit=false prior to > "checkState()" which synchronizes the readOnly property with the underlying > connection. This approach works fine with most JDBC drivers with but not > with C-JDBC. Looking at the JDBC 3 spec (10.1) JDBC says: > "Typically, a new transaction is started when the current SQL statement > requires one and there is > no transaction already in place." > The key word being "Typically". So it appears that it may be within C-JDBC's > right to declare a transaction started once setAutoCommit=false. > So, would there be any problem with changing LocalManagedConnection.begin() > to call checkState() prior to setting autoCommit in the underlying connection? > Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
