2 Replies Latest reply on Mar 7, 2002 7:16 AM by pazu

    TransactionRolledBackException: transaction timout while rem


      Here is a nice exception I've been getting most of the times I try to remove an entity (CMP 2.0):

      WARN [TxCapsule] Transaction XidImpl [FormatId=257, GlobalId=lain.wired.net//83, BranchQual=] timed out. status=STATUS_ACTIVE
      ERROR [BeanLock] Saw rolled back tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=lain.wired.net//83, BranchQual=] waiting for methodLock.
      ERROR [LogInterceptor] TransactionRolledbackException, causedBy:
      java.lang.RuntimeException: Transaction marked for rollback, possibly a timeout
       at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(QueuedPessimisticEJBLock.java:191)
       at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(QueuedPessimisticEJBLock.java:137)
       at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
       at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
       at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
       at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
       at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127)
       at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
       at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:474)
       at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:308)
       at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker$EntityProxy.invoke(BaseLocalContainerInvoker.java:412)
       at $Proxy76.getAFItemValue(Unknown Source)

      Needless to say, the stack trace goes on. A bit more information to help: there are other entities related to this one. I see SQL statements selecting the other entities on the log file. Here are them:

      DEBUG [AFAction] Removendo produto 8B80808080808180
      DEBUG [AFItem] Executing SQL: SELECT afpr_id,afpr_quantidade, afpr_referencia, afpr_descricao, afpr_preco_lista, afpr_preco_venda, afpr_af_id, afpr_prod_id FROM af_produto WHERE (afpr_id=?) OR (afpr_id=?) OR (afpr_id=?) OR (afpr_id=?) OR (afpr_id=?)
      DEBUG [AF] Executing SQL: SELECT af_numero, af_finalizada, af_pedido, af_tipo, af_data_preenchimento, af_data_pedido, af_data_prevista, af_data_entrega, af_transporte, af_total_material, af_total_servico, af_valor_cat, af_pagamento_desc, af_pagamento_tipo, af_setor, af_sistema, af_nu_ramais_analogico, af_nu_ramais_digitais, af_nu_canais, af_nu_pa, af_nu_supervisao, af_nu_stack, af_agen_id, af_clie_id FROM af WHERE (af_id=?)
      DEBUG [Cliente] Executing SQL: SELECT clie_ativ_id, clie_tipo, clie_pessoa, clie_dt_inclusao, clie_nome, clie_fantasia, clie_cgc_cpf, clie_inscest, clie_inscmun, clie_obs, clie_ende_bairro, clie_ende_cep, clie_ende_cidade, clie_ende_uf, clie_ende_fax, clie_ende_logra, clie_ende_telefone, clie_cont_bairro, clie_cont_cep, clie_cont_cidade, clie_cont_uf, clie_cont_fax, clie_cont_ende, clie_cont_telefone, clie_cobr_bairro, clie_cobr_cep, clie_cobr_cidade, clie_cobr_uf, clie_cobr_fax, clie_cobr_ende, clie_cobr_telefone, clie_contato, clie_email, clie_ativo, clie_agente_id FROM cliente WHERE (clie_id=?)
      DEBUG [AF] Executing SQL: SELECT afpr_id FROM af_produto WHERE (afpr_af_id=?)

      The first line is from my code. The log hangs just after the last line. Some minutes later I get the TransactionRolledBackException showed above.

      The relation between the beans are like this:

      AF 1 -> 1 Cliente
      AF 1 -> 1 Agente
      AF 1 -> n AFItem

      I was trying to remove a AFItem. What could be causing this transaction take so long? My application is the only one accessing the database, so I believe there is no locking issues.

        • 1. Re: TransactionRolledBackException: transaction timout while

          I'll try to help:

          1. Are you using 3.0 Alpha or Beta? I put some code into Beta that tests for application deadlock. This wouldn't help the problem, but may shed some light on things.

          2. QueuedPessimisticEJBLock should not be locking if the same transaction is active through the entire thread.
          - Are you sure there is only 1 thread active in this test scenario?
          - Do any of the beans in the relationship use RequiresNew instead of Supported or Required?
          I'm guessing that you have a circular relationship somewhere and one of the beans uses RequiresNew.

          3. Can you send me a full stack trace of the exception? I'll be able to tell right away if any beans in the relationship use RequiresNew by looking at the stack trace. bill@burkecentral.com, CC: dain@daingroup.com

          4. You say that you are doing a remove, yet I see only SELECT SQL statements.

          Basically I need more information to debug this.

          • 2. Re: TransactionRolledBackException: transaction timout while

            Here we go.

            1) 3.0.0 from CVS, checked out about a week ago (the day Dain announced the new EJB-QL parser).

            2) I'm not sure about threads, but the app is running on my machine and i'm the only one accessin it. By the way, the inteface is done via JSP's. Perhaps the web container (Jetty) do mulitiple threads, I'm not sure. And all my beans use "Requires" as transaction attribute.

            3) I'm sending the stack trace to you and Dain.

            4) That's the mostly strange. The transaction locks before the removal.