Threads blocked with the default use of JBOSS DataSource (na
Hi,
We use the following JBOSS Datasource:
<datasources>
<ha-local-tx-datasource>
<!--
The JNDI name under which the DataSource wrapper will be bound. Note that
this name is relative to the "java:/" prefix unless use-java-context is false.-->
<jndi-name>OracleDS</jndi-name>
<!-- Setting this to false will bind the DataSource into global jndi -->
<use-java-context>false</use-java-context>
<!-- An element to specify that all intermediate end(suspend) and
start(resume) calls. Also, all work on one tx will go through one
connection.
A side effect of this (currently at least) is that a connection will only
be usable by one tx until the tx commits.
<track-connection-by-tx/>
-->
<!-- The database URL . -->
<connection-url>${redbox.oracle.url}</connection-url>
<url-delimeter>;</url-delimeter>
<!-- The fully qualifed name of the javax.sql.Driver implementation class -->
<driver-class>${redbox.oracle.driver.class:oracle.jdbc.OracleDriver}</driver-class>
<!-- The login and password. Remplace
<user-name>${redbox.oracle.username}</user-name>
<?xml version="1.0"?>
<!DOCTYPE connection-factories
PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
"http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd">
<!-- The Hypersonic embedded database JCA connection factory config
$Id: oracle-nonxa-ds.xml,v 1.4 2006/05/18 07:21:38 pignace Exp $ -->
<datasources>
<ha-local-tx-datasource>
<!--
The JNDI name under which the DataSource wrapper will be bound. Note that
this name is relative to the "java:/" prefix unless use-java-context is false.-->
<jndi-name>OracleDS</jndi-name>
<!-- Setting this to false will bind the DataSource into global jndi -->
<use-java-context>false</use-java-context>
<!-- An element to specify that all intermediate end(suspend) and
start(resume) calls. Also, all work on one tx will go through one
connection.
A side effect of this (currently at least) is that a connection will only
be usable by one tx until the tx commits.
<track-connection-by-tx/>
-->
<!-- The database URL . -->
<connection-url>${redbox.oracle.url}</connection-url>
<url-delimeter>;</url-delimeter>
<!-- The fully qualifed name of the javax.sql.Driver implementation class -->
<driver-class>${redbox.oracle.driver.class:oracle.jdbc.OracleDriver}</driver-class>
<!-- The login and password. Remplace
<user-name>${redbox.oracle.username}</user-name>
<password>${redbox.oracle.password}</password>
-->
<connection-property name="User">${redbox.oracle.username}</connection-property>
<connection-property name="Password">${redbox.oracle.password}</connection-property>
<user-name>${redbox.oracle.username}</user-name>
<password>${redbox.oracle.password}</password>
<!--example of how to specify class that determines if exception means connection should be destroyed-->
<!--exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.DummyExceptionSorter</exception-sorter-class-name-->
<!-- this will be run before a managed connection is removed from the pool for use by a client-->
<!-- new-connection-sql>select DUMMY from DUAL</new-connection-sql -->
<!-- The minimum connections in a pool/sub-pool. Pools are lazily constructed on first use -->
<min-pool-size>1</min-pool-size>
<!-- The maximum connections in a pool/sub-pool -->
<max-pool-size>10</max-pool-size>
<!-- The time before an unused connection is destroyed -->
<!-- NOTE: This is the check period. It will be destroyed somewhere between 1x and 2x this timeout after last use -->
<!-- TEMPORARY FIX! - Disable idle connection removal, HSQLDB has a problem with not reaping threads on closed connections -->
<idle-timeout-minutes>1</idle-timeout-minutes>
<!-- sql to call when connection is created -->
<new-connection-sql>select DUMMY from DUAL</new-connection-sql>
<!-- sql to call on an existing pooled connection when it is obtained from pool -->
<check-valid-connection-sql>select DUMMY from DUAL</check-valid-connection-sql>
<!-- Oracles XA datasource cannot reuse a connection outside a transaction once enlisted in a global transaction and vice-versa -->
<no-tx-separate-pools/>
<!-- example of how to specify a class that determines a connection is valid before it is handed out from the pool -->
<valid-connection-checker-class-name>
org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker
</valid-connection-checker-class-name>
<!-- Checks the Oracle error codes and messages for fatal errors -->
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<!-- Whether to check all statements are closed when the connection is returned to the pool,
this is a debugging feature that should be turned off in production -->
<track-statements/>
<!-- Use the getConnection(user, pw) for logins
<application-managed-security/>
-->
<!-- Use the security domain defined in conf/login-config.xml -->
<!-- security-domain>HsqlDbRealm</security-domain -->
<!-- Use the security domain defined in conf/login-config.xml or the
getConnection(user, pw) for logins. The security domain takes precedence.
<security-domain-and-application>HsqlDbRealm</security-domain-and-application>
-->
<!-- set-tx-query-timeout/ -->
<!-- query-timeout>10</query-timeout -->
<type-mapping>Oracle9i</type-mapping>
</ha-local-tx-datasource>
</datasources>Sometimes, we noticed that 2 threads are locked (see the following thread dump):
Open lock chains ================ Chain 1: "http-0.0.0.0-8080-3" id=306 idx=0x9a tid=4669 waiting for oracle/jdbc/driver/T4CCon nection@0x1cb77700 held by: "http-0.0.0.0-8080-2" id=305 idx=0x98 tid=4668 (active) ===== END OF THREAD DUMP =============== "http-0.0.0.0-8080-3" id=306 idx=0x9a tid=4669 prio=5 alive, in native, interrupted, blocked, daemon -- Blocked trying to get lock: oracle/jdbc/driver/T4CConnection@0x1cb77700[thin lock] at _dl_sysinfo_int80+2(:0)@0x4737a2 at ptWaitForEvent+45(:0)@0xb7ec8481 at vmtWaitUntilNotSoftSuspended+67(:0)@0xb7ed39f7 at tsCheckTransitToJava+26(:0)@0xb7ed3a4a at jrockit/vm/Threads.shortNap(I)V(Native Method) at jrockit/vm/Locks.waitForThinRelease(Ljava/lang/Object;I)I(Unknown Source) at jrockit/vm/Locks.monitorEnterSecondStage(Ljava/lang/Object;I)Ljava/lang/Object; (Unknown Source) at jrockit/vm/Locks.monitorEnter(Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)[optimized] at oracle/jdbc/driver/PhysicalConnection.prepareStatement(Ljava/lang/String;)Ljava/sql/PreparedStatement;(PhysicalCon nection.java:651) "http-0.0.0.0-8080-2" id=305 idx=0x98 tid=4668 prio=5 alive, in native, interrupted, daemon at _dl_sysinfo_int80+0(:0)@0x4737a0 at RJNI_jrockit_net_SocketNativeIO_readBytesPinned+180(:0)@0xb7eb1428 at jrockit/net/SocketNativeIO.readBytesPinned(I[BIII)I(Native Method) at jrockit/net/SocketNativeIO.socketRead(Ljava/io/FileDescriptor;[BIII)I(Unknown Source) at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(Unknown S ource) at java/net/SocketInputStream.read([BII)I(SocketInputStream.java:129) at oracle/net/ns/Packet.receive()V(Unknown Source) at oracle/net/ns/DataPacket.receive()V(Unknown Source) at oracle/net/ns/NetInputStream.getNextPacket()V(Unknown Source) at oracle/net/ns/NetInputStream.read([BII)I(Unknown Source) at oracle/net/ns/NetInputStream.read([B)I(Unknown Source) at oracle/net/ns/NetInputStream.read()I(Unknown Source) at oracle/jdbc/driver/T4CMAREngine.unmarshalUB1()S(T4CMAREngine.java:978) at oracle/jdbc/driver/T4CMAREngine.unmarshalSB1()B(T4CMAREngine.java:950) at oracle/jdbc/driver/T4C8Oall.receive()V(T4C8Oall.java:434) at oracle/jdbc/driver/T4CPreparedStatement.doOall8(ZZZZ)V(T4CPreparedStatement.java:181) at oracle/jdbc/driver/T4CPreparedStatement.execute_for_rows(Z)V(T4CPreparedStatement.java:629) at oracle/jdbc/driver/OracleStatement.doExecuteWithTimeout()V(OracleStatement.java:1080) at oracle/jdbc/driver/OraclePreparedStatement.executeInternal()I(OraclePreparedS tatement.java:2904) at oracle/jdbc/driver/OraclePreparedStatement.executeUpdate()I(OraclePreparedStatement.java:2976) ^-- Holding lock: oracle/jdbc/driver/T4CConnection@0x1cb77700[thin lock] ^-- Holding lock: oracle/jdbc/driver/T4CPreparedStatement@0x1dd23f38[thin lock] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Is it a bug of the JDBC driver or the JBOSS datasource implementation? At any rate, if we use the C3P0 connection pool instead of JBOSS ManagedConnectionPool, the problem of blocked threads do not occur any more.
Do you have an explaination?
Thanks in advance.
Best Regards,
David
