[
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