Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] bug 326461 - avoid deadlocks on MaxDB 
Hi Adrien,
This exception is occurring because of the fact that the JBoss testing is running only JPA 1.0 tests and the change that was made adds a JPA 2.0 class. Our strategy for dealing with JPA 1.0 support causes this issue.
I will discuss with some of the engineers here and come up with a solution. For now, don't worry about this issue. 

-Tom

Kevin Yuan wrote:

Hi Adrian,
All JPQL testing failed on JBossEAP 5.0.0 seems to be related to your change with "org.eclipse.persistence.testing.tests.jpa.jpql.AdvancedQueryTestSuite" (revision: 8276). I have filed a bug: 327937 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=327937>. Could you have a look at. 

Thanks,
Kevin

On 01/10/2010 4:42 AM, Goerler, Adrian wrote:

Hi,
_https://bugs.eclipse.org/bugs/show_bug.cgi?id=326461_ Reviewed by Yiping and Gordon. Checked in in trunk. -Adrian 

    ------------------------------------------------------------------------
    *Von:* Gordon Yorke [mailto:gordon.yorke@xxxxxxxxxx]
    *Gesendet:* Donnerstag, 30. September 2010 21:30
    *An:* Yiping Zhao
    *Cc:* Goerler, Adrian
    *Betreff:* Re: AW: [Fwd: [eclipselink-dev] bug 326461 - avoid
    deadlocks on MaxDB]

    The em2.find can be read before the lock occurs.  It is the
    failure of the update that is being tested and the test appears to
    continue to validate that changes from EM2 do not make it to the
    database.  So no objections.
    --Gordon

    Yiping Zhao wrote:

    Hi Adrian,

    I brought this concern here just because I want to make sure the
    test still tests the functionality correctly after alteration,
    but I don't know much details about the pessimistic locking,
    check with Gordon, if he deosn't have objections, that should be
    fine.

    Yiping

    On 30/09/2010 12:31 PM, Goerler, Adrian wrote:

    Hi Yiping,
thanks for the feedback. in the AdvancedQueryTestSuite, I had to find a solution for the 
    following issue:
when tx1 places a pessimistic lock, I am using an *exclusive* 
    lock on MaxDB. This later blocks em2.find before tx2 can even
    atempt to lock. To avoid blocking of tx2, I replaced em2.find by
    a query and rearanged this before tx1.lock. While this avoids
    the deadlock,I am losing the assertion that em2.find is
    non-blocking.
Ideally, I would place a *shared* read lock as lock mode READ is 
    specified, which would not block em2.find. However, I am under
    the impression that the distinction between PESSIMISTIC_READ
    locks and PESSIMISTIC_WRITE locks cannot be made in the database
    platform. Hence I am propagating the READ lock to a WRITE lock
    (which is in agreement with the spec).
-Adrian 
        ------------------------------------------------------------------------
        *Von:* Yiping Zhao [mailto:yiping.zhao@xxxxxxxxxx]
        *Gesendet:* Donnerstag, 30. September 2010 17:56
        *An:* Goerler, Adrian
        *Cc:* eclipselink-dev@xxxxxxxxxxx; GORDON_YORKE
        *Betreff:* Re: [Fwd: [eclipselink-dev] bug 326461 - avoid
        deadlocks on MaxDB]

        Hi Adrian,

        Sorry for the late reply, I saw the email too late until
        yesterday late afternoon.

        I think the changes are OK, you simplified the
        PessimisticLockingExtendedScopeTestSuite.java a lot, that's
        great. For the changes in AdvancedQueryTestSuite.java, you
        changed the sequences of entities operations, I am not sure
        if that will do same thing as the original one:

        Original:
                    starts tx1; tx1 does query and sets lock mode
        using query.setLockMode() for read lock, modifies entity;
                    starts tx2; tx2 reads entity, locks it using em
        with 0 timeout and updates, lock can't be obtained and
        results in transaction-level rollback and throws
        PessimisticLockException


        Yours:
                   starts tx1; starts tx2, tx2 reads entity, tx1
        reads and modifies entity, locks it as read lock and
        updates; tx2 locks entity and updates

        Maybe Gordon can confirm that.

        Thanks,
        Yiping



        Yiping, Gordon, all,
_https://bugs.eclipse.org/bugs/show_bug.cgi?id=326461_ Some tests of PessimisticLockingExtendedScopeTestSuite and 
        AdvancedQueryTestSuite are deadlocking on MaxDB.
Moreover, it turned out that pessimistic lock scope 
        EXTENDED was not locking properly on MySQL.
I am proposing a patch for these issues: _https://bugs.eclipse.org/bugs/attachment.cgi?id=179824_ Could you please have a look? Thanks and regards, Adrian SAP AG 
        Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
Sitz der Gesellschaft/Registered Office: Walldorf, Germany 
        Vorstand/SAP Executive Board: Henning Kagermann
        (Sprecher/CEO), Léo Apotheker (stellvertretender
        Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich,
        Gerhard Oswald, John Schwarz, Peter Zencke
        Vorsitzender des Aufsichtsrats/Chairperson of the SAP
        Supervisory Board: Hasso Plattner
        Registergericht/Commercial Register Mannheim No HRB 350269



------------------------------------------------------------------------

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


------------------------------------------------------------------------

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top