|
Hi,
Reviewed by Yiping and Gordon.
Checked in in trunk.
-Adrian
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
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,
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,
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
|
