[jboss-user] [JCA/JBoss] - Threads blocked with the default use of JBOSS DataSource (na

dmindupto do-not-reply at jboss.com
Wed Oct 31 07:29:53 EDT 2007


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 at 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 at 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 at 0x1cb77700[thin lock]
  | ^-- Holding lock: oracle/jdbc/driver/T4CPreparedStatement at 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

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100588#4100588

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100588



More information about the jboss-user mailing list