Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] [Fwd: bug 326461 - avoid deadlocks on MaxDB]

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).

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 a lot, that's great. For the changes in, you changed the sequences of entities operations, I am not sure if that will do same thing as the original one:

            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

           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.


Yiping, Gordon, all,
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:
Could you please have a look?
Thanks and regards,
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

Back to the top