[JBoss JIRA] Created: (JBJCA-46) Unnecessary Locking in WrappedConnection and WrappedPreparedStatement
7:20 p.m.
Unnecessary Locking in WrappedConnection and WrappedPreparedStatement
---------------------------------------------------------------------
Key: JBJCA-46
URL: https://jira.jboss.org/jira/browse/JBJCA-46
Project: JBoss JCA
Issue Type: Bug
Components: JDBC
Environment: Windows
Sun JDK 1.6
Reporter: Deyan Bektchiev
Assignee: Jesper Pedersen
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
9:38 a.m.
New subject: [JBoss JIRA] Moved: (JBAS-6587) Unnecessary Locking in WrappedConnection and WrappedPreparedStatement
[
https://jira.jboss.org/jira/browse/JBAS-6587?page=com.atlassian.jira.plug...
]
Jesper Pedersen moved JBJCA-46 to JBAS-6587:
--------------------------------------------
Project: JBoss Application Server (was: JBoss JCA)
Key: JBAS-6587 (was: JBJCA-46)
Issue Type: Feature Request (was: Bug)
Component/s: JCA service
(was: JDBC)
Security: Public
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
Assignee: Jesper Pedersen
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
9:38 a.m.
New subject: [JBoss JIRA] Updated: (JBAS-6587) Unnecessary Locking in WrappedConnection and WrappedPreparedStatement
[
https://jira.jboss.org/jira/browse/JBAS-6587?page=com.atlassian.jira.plug...
]
Jesper Pedersen updated JBAS-6587:
----------------------------------
Priority: Minor (was: Major)
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
Assignee: Jesper Pedersen
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
8:28 a.m.
New subject: [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.
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
4:51 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6587) Unnecessary Locking in WrappedConnection and WrappedPreparedStatement
[
https://jira.jboss.org/jira/browse/JBAS-6587?page=com.atlassian.jira.plug...
]
Christian Naeger commented on JBAS-6587:
----------------------------------------
Hi Adrian,
this issue is closed, so I don't know if my comment reaches you.
I also used YourKit to profile an app deployed on a JBoss 4.2.3 with an underlying MySQL
database.
Basically all stack traces where time is spent boil down to the following:
<pre>
-> our stuff
--> some Hibernate method time spent so far: 1%
----> org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery() time
spent in this method: 95%
-------> net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery() time spent in
this method: 4%
</pre>
The interesting thing now is that 95% of the time is spent in WrappedPreparedStatement,
BUT ONLY 4% in JtdsPreparedStatement.executeQuery().
So it looks as if 95% of the time is spent inside Jboss and only 4% in the actual query to
the database!!!
This also complies with the observation that our application is terribly slow, but the
database load is still quite low.
I debugged into org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery() to
see where this time could have been spent and I have the suspicion it is in the
synchronized(stateLock) block of the following method (called from
WrappedPreparedStatement.executeQuery()):
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction()
So is this really the desired behaviour? Or are we doing something completely wrong
(likely :-)?
Any help is highly appreciated!
Regards,
Christian Naeger
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
6045
days inactive
6289
days old
4 comments
4 participants
participants (4)
-
Adrian Brock (JIRA) -
Christian Naeger (JIRA)
-
Deyan Bektchiev (JIRA)
-
Jesper Pedersen (JIRA)