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