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

[Adrian Brock (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBAS-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.

> Unnecessary Locking in WrappedConnection and WrappedPreparedStatement
> ---------------------------------------------------------------------
>
>                 Key: JBAS-6587
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>         Environment: Windows 
> Sun JDK 1.6
>            Reporter: Deyan Bektchiev
>            Priority: Minor
>
> The JBoss JDBC Connection and PreparedStatement wrapper classes all acquire and release a lock when entering and exiting most of their methods.
> JDBC connections are not supposed to be thread safe and even if you coded your wrapper this way there is no guarantee that the underlying Connection would behave properly if accessed by multiple threads concurrently.
> In one particular use case when profiling obtaining the locks for Statements (that obtain the Connection locks) took 5% of the total time.
> I can provide a YourKit CPU profiler snapshot.
> Regards,
> Deyan

-- 
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