[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] FW: bug 327472 - testPESSMISTIC_ES5

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