2 Replies Latest reply on Jan 26, 2009 8:37 AM by bcoutinho

    TxConnectionManager error IllegalMonitorStateException

    bcoutinho

      We are migrating our app from JBossAS 4.2.0 to 4.2.3. The app worked ok in 4.2.0. As far as we can tell, everything is also working fine in 4.2.3 but for one problem. We started getting the following exception:

      2009-01-14 00:42:02,091 WARN [org.jboss.resource.connectionmanager.TxConnectionManager] Error during tidyup org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@69ad0281[state=DESTROYED mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection@6b29832c handles=0 lastUse=1231900880359 permit=false trackByTx=false mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool@6af48216 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@674558d9 xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@69ad027b txSync=null]
      java.lang.IllegalMonitorStateException
       at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
       at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1102)
       at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
       at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:278)
       at org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.rollback(LocalManagedConnection.java:94)
       at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.tidyup(TxConnectionManager.java:698)
       at org.jboss.resource.connectionmanager.BaseConnectionManager2.returnManagedConnection(BaseConnectionManager2.java:359)
       at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:632)
       at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:363)
       at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:155)
       at com.wxyz.ejb.SequentialSetterBean.closeConnection(SequentialSetterBean.java:123)
       at com.wxyz.ejb.SequentialSetterBean.getNextSequential(SequentialSetterBean.java:61)
       at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
       at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:116)
       at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
       at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
       at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
       at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
      


      Our SequentialSetterBean code is:

      package com.wxyz.ejb;
      ...
      @Stateless
      @Remote(com.wxyz.ejb.SequentialSetter.class)
      @Local(com.wxyz.ejb.SequentialSetter.class)
      public class SequentialSetterBean implements SequentialSetter {
      
       @Resource(mappedName="java:wxyzDS") DataSource wxyzDS;
      
       @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
       public Integer getNextSequential(String name) {
       Connection connection = null;
       CallableStatement statement = null;
       Integer sequential = null;
       try {
       connection = wxyzDS.getConnection();
       statement = connection.prepareCall("{call wxyz.next_sequential(?, ?)}");
       statement.setString(1, name);
       statement.registerOutParameter(2, Types.INTEGER);
       statement.execute();
       sequential = statement.getInt(2);
       if (sequential == null || 0 == sequential) {
       throw new UncheckedException("Invalid sequential " + sequential + " returned to " + name);
       }
       return sequential;
       } catch (Exception e) {
       throw new UncheckedException(e.getMessage(), e);
       } finally {
       closeStatement(statement);
       closeConnection(connection);
       }
       }
      
       private void closeResultSet(ResultSet resultSet) {
       if (resultSet != null) {
       try {
       resultSet.close();
       } catch (SQLException e) {
       logger.error(e);
       }
       }
       }
      
       private void closeStatement(Statement statement) {
       if (statement != null) {
       try {
       statement.close();
       } catch (SQLException e) {
       logger.error(e);
       }
       }
       }
      
       private void closeConnection(Connection connection) {
       if (connection != null) {
       try {
       connection.close();
       } catch (SQLException e) {
       logger.error(e);
       }
       }
       }
      }
      


      Note that we are using trans atrribute NOT_SUPPORTED because we want the procedure to control the transaction.

      Our DataSource is:

      <datasources>
       <local-tx-datasource>
       <jndi-name>wxyzDS</jndi-name>
       <connection-url><![CDATA[jdbc:mysql:loadbalance://192.168.11.5:3306,192.168.11.6:3306/?loadBalanceStrategy=random&loadBalanceBlacklistTimeout=5000&useServerPrepStmts=false&useConfigs=maxPerformance]]></connection-url>
       <driver-class>com.mysql.jdbc.Driver</driver-class>
       <user-name>user</user-name>
       <password>********</password>
       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
       <min-pool-size>2</min-pool-size>
       <max-pool-size>50</max-pool-size>
       <blocking-timeout-millis>5000</blocking-timeout-millis>
       <idle-timeout-minutes>5</idle-timeout-minutes>
      
       <exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name>
       <valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name>
       <check-valid-connection-sql>select 1</check-valid-connection-sql>
       <new-connection-sql>select 1</new-connection-sql>
      
       <metadata>
       <type-mapping>mySQL</type-mapping>
       </metadata>
       </local-tx-datasource>
      </datasources>
      


      Inspecting BaseWrapperManagedConnection, we've noticed that the above unlock() method was introduced only in 4.2.3, so we suspect that this issue is related to this new implementation.

      Has someone some clue to this error?

      TIA.

      --
      Bill Coutinho.