[jboss-jira] [JBoss JIRA] Updated: (JBAS-8626) QueuedPessimisticEJBLock released to early

Judith Bürgstein (JIRA) jira-events at lists.jboss.org
Thu Nov 11 03:01:01 EST 2010


     [ https://jira.jboss.org/browse/JBAS-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Judith Bürgstein updated JBAS-8626:
-----------------------------------

    Description: 
Usecase:
All xx, xy, yy and xz are representing readonly entitybean-methods and are called on one EntityBean. CMT required and reentrant true.
The following methods are executed on the server in this order: 

Thread1: calls entitybean.xx
Thread1: calls entitybean.xy
Thread2: calls entitybean.yy -> has to wait for the QueuedPessimisticEJBLock
Thread1: returns from entitybean.xy and frees the QueuedPessimisticEJBLock                    <--- BUG
Thread2: gets the QueuedPessimisticEJBLock but doesn't get the NonReentrantLock
Thread1: calls entitybean.xz -> has to wait for the QueuedPessimisticEJBLock and still holds the NonReentrantLock
Result: Undetected deadlock between QueuedPessimisticEJBLock and NonReentrantLock.

Please use the attached bug-0.1-SNAPSHOT.jar for verification. Main class for the test is locking.bug.DeadlockTest.


Our current workaround:
Created a subclass of QueuedPessimisticEJBLock and override problematic method "endInvocation":

public void endInvocation(Invocation P_mi)
    {
        Transaction F_tx = P_mi.getTransaction();
        if (F_tx != null && F_tx.equals(getTransaction()))
        {
            EntityEnterpriseContext F_ctx = (EntityEnterpriseContext)P_mi.getEnterpriseContext();

            if(F_ctx == null)
            {
                endTransaction(F_tx);
            }
            else if(F_ctx.hasTxSynchronization() == false)
            {
                NonReentrantLock F_mLock = F_ctx.getMethodLock();
                
                if (F_mLock == null)
                {
                    endTransaction(F_tx);
                }
                else
                {
                    Object F_resourceHolder = F_mLock.getResourceHolder();
                    if (F_resourceHolder instanceof Thread
                            && Thread.currentThread().equals(F_resourceHolder))
                    {
                        // don't end the transaction, because we still own the
                        // lock!
                    }
                    else if (F_resourceHolder instanceof Transaction
                            && F_tx.equals(F_resourceHolder))
                    {
                        // don't end the transaction, because we still own the
                        // lock!
                    }
                    else
                    {
                        endTransaction(F_tx);
                    }
                }
            }
            else
            {
                //hasTxSynchronization is true -> don't end the transaction
            }
        }
    }

  was:
Usecase:
All xx, xy, yy and xz are representing readonly entitybean-methods and are called on one EntityBean. CMT required and reentrant true.
The following methods are executed on the server in this order: 

Thread1: calls entitybean.xx
Thread1: calls entitybean.xy
Thread2: calls entitybean.yy -> has to wait for the QueuedPessimisticEJBLock
Thread1: returns from entitybean.xy and frees the QueuedPessimisticEJBLock                    <--- BUG
Thread2: gets the QueuedPessimisticEJBLock but doesn't get the NonReentrantLock
Thread1: calls entitybean.xz -> has to wait for the QueuedPessimisticEJBLock and still holds the NonReentrantLock
Result: Undetected deadlock between QueuedPessimisticEJBLock and NonReentrantLock.

Our current workaround:
Created a subclass of QueuedPessimisticEJBLock and override problematic method "endInvocation":

public void endInvocation(Invocation P_mi)
    {
        Transaction F_tx = P_mi.getTransaction();
        if (F_tx != null && F_tx.equals(getTransaction()))
        {
            EntityEnterpriseContext F_ctx = (EntityEnterpriseContext)P_mi.getEnterpriseContext();

            if(F_ctx == null)
            {
                endTransaction(F_tx);
            }
            else if(F_ctx.hasTxSynchronization() == false)
            {
                NonReentrantLock F_mLock = F_ctx.getMethodLock();
                
                if (F_mLock == null)
                {
                    endTransaction(F_tx);
                }
                else
                {
                    Object F_resourceHolder = F_mLock.getResourceHolder();
                    if (F_resourceHolder instanceof Thread
                            && Thread.currentThread().equals(F_resourceHolder))
                    {
                        // don't end the transaction, because we still own the
                        // lock!
                    }
                    else if (F_resourceHolder instanceof Transaction
                            && F_tx.equals(F_resourceHolder))
                    {
                        // don't end the transaction, because we still own the
                        // lock!
                    }
                    else
                    {
                        endTransaction(F_tx);
                    }
                }
            }
            else
            {
                //hasTxSynchronization is true -> don't end the transaction
            }
        }
    }



> QueuedPessimisticEJBLock released to early
> ------------------------------------------
>
>                 Key: JBAS-8626
>                 URL: https://jira.jboss.org/browse/JBAS-8626
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-5.1.0.GA
>            Reporter: Judith Bürgstein
>         Attachments: bug-0.1-SNAPSHOT.jar, jboss_logfile.log, source.jar
>
>
> Usecase:
> All xx, xy, yy and xz are representing readonly entitybean-methods and are called on one EntityBean. CMT required and reentrant true.
> The following methods are executed on the server in this order: 
> Thread1: calls entitybean.xx
> Thread1: calls entitybean.xy
> Thread2: calls entitybean.yy -> has to wait for the QueuedPessimisticEJBLock
> Thread1: returns from entitybean.xy and frees the QueuedPessimisticEJBLock                    <--- BUG
> Thread2: gets the QueuedPessimisticEJBLock but doesn't get the NonReentrantLock
> Thread1: calls entitybean.xz -> has to wait for the QueuedPessimisticEJBLock and still holds the NonReentrantLock
> Result: Undetected deadlock between QueuedPessimisticEJBLock and NonReentrantLock.
> Please use the attached bug-0.1-SNAPSHOT.jar for verification. Main class for the test is locking.bug.DeadlockTest.
> Our current workaround:
> Created a subclass of QueuedPessimisticEJBLock and override problematic method "endInvocation":
> public void endInvocation(Invocation P_mi)
>     {
>         Transaction F_tx = P_mi.getTransaction();
>         if (F_tx != null && F_tx.equals(getTransaction()))
>         {
>             EntityEnterpriseContext F_ctx = (EntityEnterpriseContext)P_mi.getEnterpriseContext();
>             if(F_ctx == null)
>             {
>                 endTransaction(F_tx);
>             }
>             else if(F_ctx.hasTxSynchronization() == false)
>             {
>                 NonReentrantLock F_mLock = F_ctx.getMethodLock();
>                 
>                 if (F_mLock == null)
>                 {
>                     endTransaction(F_tx);
>                 }
>                 else
>                 {
>                     Object F_resourceHolder = F_mLock.getResourceHolder();
>                     if (F_resourceHolder instanceof Thread
>                             && Thread.currentThread().equals(F_resourceHolder))
>                     {
>                         // don't end the transaction, because we still own the
>                         // lock!
>                     }
>                     else if (F_resourceHolder instanceof Transaction
>                             && F_tx.equals(F_resourceHolder))
>                     {
>                         // don't end the transaction, because we still own the
>                         // lock!
>                     }
>                     else
>                     {
>                         endTransaction(F_tx);
>                     }
>                 }
>             }
>             else
>             {
>                 //hasTxSynchronization is true -> don't end the transaction
>             }
>         }
>     }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



More information about the jboss-jira mailing list