All JPQL testing failed on JBossEAP 5.0.0 seems to be related to your
(revision: 8276). I have filed a bug: 327937.
Could you have a look at.
On 01/10/2010 4:42 AM, Goerler, Adrian wrote:
Reviewed by Yiping and
Checked in in trunk.
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
Yiping Zhao wrote:
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.
On 30/09/2010 12:31 PM, Goerler, Adrian wrote:
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
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).
Sorry for the late reply, I saw the email too late until yesterday late
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
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
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,
16, 69190 Walldorf, Germany
Gesellschaft/Registered Office: Walldorf, Germany
Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker
(stellvertretender Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich,
Gerhard Oswald, John Schwarz, Peter Zencke
Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner
Register Mannheim No HRB 350269
eclipselink-dev mailing list