[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipselink-dev] FW: bug 327472 - testPESSMISTIC_ES5
- From: "Goerler, Adrian" <adrian.goerler@xxxxxxx>
- Date: Fri, 19 Nov 2010 15:49:46 +0100
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcuH8QOeAn/HCFCISZ292P/RAI8xQgAAiZNw
- Thread-topic: [eclipselink-dev] FW: bug 327472 - testPESSMISTIC_ES5
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?
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
I am ok with the test change.
Is there anything shown by this test we should document on MaxDBPlatform?
Goerler, Adrian wrote:
> 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)?
> *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
> 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?
> *Adrian Görler
> **SAP AG
> *Pflichtangaben/Mandatory Disclosure Statements:
> eclipselink-dev mailing list
eclipselink-dev mailing list