[jboss-jira] [JBoss JIRA] Closed: (JBAS-6587) Unnecessary Locking in WrappedConnection and WrappedPreparedStatement

[ https://jira.jboss.org/jira/browse/JBAS-6587?page=com.atlassian.jira.plug... ] Adrian Brock closed JBAS-6587. ------------------------------ Resolution: Rejected Assignee: (was: Jesper Pedersen) JDBC Connections ARE required to be threadsafe. http://java.sun.com/products/jdbc/driverdevs.html A.1.6 - Support Multithreading "Some drivers may allow more concurrent execution than others, but developers should be able to assume fully concurrent execution. If the driver requires some form of synchronization, then the driver should provide it. In this situation, the only difference visible to the developer should be that applications run with reduced concurrency." In our case the jdbc resource adapter has to "lock" to ensure there is no "race" between commits/rollbacks and normal execution, see e.g. JBAS-5080 Absent the "race" occuring (when you need it) there should be no contention on these locks (at least for normal javaee usage - i.e. non concurrent of connections across threads). Compared with the time taken doing the I/O with the database it will be negligble. It might be 5% of cpu (the size of that number is almost certainly an artifact of the profiler because of the number of method calls), but in terms of wall clock time the cpu time will be much less than the overall request time which will include network waits while the database operation are run. You can provide patches for specific optimizations if you can find them, but these should not over complicate the code more than it is. ;-) And they should look like they work in all environments, not just the specific JVM/OS/Driver/Network/Database you are testing with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira