1 Reply Latest reply on Nov 6, 2007 12:27 AM by Vicky Kak

    Threads blocked with the default use of JBOSS DataSource (na

    Nicolas Duval Newbie

      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

        • 1. Re: Threads blocked with the default use of JBOSS DataSource
          Vicky Kak Master

           

          "dmindupto" wrote:

          Sometimes, we noticed that 2 threads are locked (see the following thread dump):

          This can be normal , all I wanted to know is if this locking continues for longer time .
          You should analyze the set of thread dumps(4 to 5) after the fixed intervals of 10-15 minutes , this will let you know if this is leading to deadlock which should be the point of concern .
          If this leads to deadlock you might need to get help from the oracle support .