Hi Tom,
thanks for checking.
I think we could add something like:
Pessimistic locking with lock scope EXTENDED should be used cautiously in the presence of foreign key constraints: Locking an entity with lock scope EXTENDED will reliably block concurrent access to join table rows held by the locked entity causing the concurrent transaction to wait. However, in this situation, attempting to access a collection-valued relationship owned by the locked entity can lead to a deadlock causing the transaction that obtained the pessimistic lock to be rolled back. See bug 327472.
(which is not easily understandable - feel free to rephrase ;-) ) Alternatively, we could just state:
Pessimistic locking with lock scope EXTENDED should not be used in the presence of foreign key constraints. See bug 327472.
What do you think?
-Adrian
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx] On Behalf Of Tom Ware
Sent: Freitag, 19. November 2010 14:50
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] FW: bug 327472 - testPESSMISTIC_ES5
Hi Adrian,
I am ok with the test change.
Is there anything shown by this test we should document on MaxDBPlatform?
-Tom
Goerler, Adrian wrote:
Hi,
I have not received any feedback on this. Could anyone please have a
look at the proposed patch so that I can proceed with it (or look for an
alternative solution)?
Thanks,
Adrian
_____________________________________________
*From:* Goerler, Adrian
*Sent:* Freitag, 22. Oktober 2010 09:19
*To:* Dev mailing list for Eclipse Persistence Services
*Cc:* kwesi@xxxxxxx
*Subject:* bug 327472 - testPESSMISTIC_ES5
Hi,
_https://bugs.eclipse.org/bugs/show_bug.cgi?id=327472_
this issue is due to a particularity in the order, which MaxDB uses to
lock tables in the presence of FK constraints. Seems that MaxDB can't
change this.
I am proposing to use a native query on MaxDB to assert that pessimistic
locking with lock scope EXTENDED guarantees repeatable read on the join
table (as required by the spec).
Could you please have a look?
Thanks,
Adrian
*Adrian Görler
**SAP AG
*Pflichtangaben/Mandatory Disclosure Statements:
_http://www.sap.com/company/legal/impressum.epx_
------------------------------------------------------------------------
_______________________________________________
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