1 Reply Latest reply on Oct 19, 2001 10:59 PM by davidjencks

    Transaction Deadlock with Multiple Pools

    woofbot

      In my code, I have two beans which access separate database pools. In the first bean, a method is called which makes some database calls and then it calls a function on the second bean which also makes some database calls. The problem I am having is that when the second bean attempts to make its calls, JBoss seems to go into a transaction deadlock state. Eventually, the following message is printed out to the logs, but the method never returns.

      10-19-01 10:28 {Container factory} logToCategory - Transaction XidImpl [FormatId=257, GlobalId=itcoa165//18, BranchQual=] timed out. status=STATUS_ACT
      IVE


      I am using JBoss 2.4.1 with Sybase's JConnect 5.5 drivers. Both methods are set for required and the datasources are configred for TRANSACTION_READ_UNCOMMITTED The mbean configuration for the two pools follows.


      hms_pool
      org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl

      jdbc:sybase:Tds:SOCDB004:25000/testdb
      1200000
      *****
      10
      *****
      false
      false
      false
      true
      120000
      1800000
      false
      false
      1.0
      0



      finance_pool
      org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl

      jdbc:sybase:Tds:SOCDB004:25000/testdb
      1200000
      *****
      10
      *****
      false
      false
      false
      true
      120000
      1800000
      false
      false
      1.0
      0


      Has anyone encountered something similar to this?

      -Mike Wolf

        • 1. Re: Transaction Deadlock with Multiple Pools
          davidjencks

          Maybe this is db deadlock? Is it possible one connection is causing a lock on something the other connection is trying to read or write? I don't know if the dirty read prevents all locking in Sybase. What happens if you try transaction none? If it still deadlocks it's probably the driver. What happens if you use just one pool? Since you are using a fake xa wrapper, you are effectively executing 2 database transactions - if the transaction on the second fails you will have inconsistent results.