openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Curtis (JIRA)" <>
Subject [jira] Updated: (OPENJPA-1604) Setting PessimisticLockManager fails to append "for update clause" to the select statement
Date Thu, 08 Apr 2010 18:35:43 GMT


Rick Curtis updated OPENJPA-1604:

    Attachment: OPENJPA-1604-trunk.patch

After digging into this problem I concur with Pinaki's assessment that the lock modes / lock
configuration has numerous issues. I'm posting a patch that will only address the backward
compatibility issue. 

The root issue at hand is that in JPA 1.0 a named query had a default lock mode of READ (by
OpenJPA's definition, not the spec), but per the 2.0 spec the default lock mode is NONE.

Ideally when we are parsing annotations in AnnotationPersistenceMetaDataParser we could differentiate
between a named query which has specified the lockMode vs a default lockMode. Since that doesn't
seem to be possible, I'm proposing that if we detect that we're using a pessimistic lock manager
and the lockMode is none, we will promote that lock to a READ lock.

This approach will restore backward compatibility, but will exclude one use case. When using
a pessimistic lock manager on 2.0 you will be unable to configure a NamedQuery with the lockMode
of NONE. 

> Setting PessimisticLockManager fails to append "for update clause" to the select statement
> ------------------------------------------------------------------------------------------
>                 Key: OPENJPA-1604
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 2.0.0, 2.1.0
>            Reporter: Fay Wang
>            Assignee: Pinaki Poddar
>             Fix For: 2.0.0, 2.1.0
>         Attachments: OPENJPA-1604-2.0.x.patch, OPENJPA-1604-trunk.patch
>  I ran a testcase against openjpa 1.2, and found that the "for update" clause is appended
to the SQL when
>  		<property name="openjpa.LockManager" value="pessimistic"/>
> 	is added to the persistence.xml without calling: 
> 		 q.setLockMode(LockModeType.PESSIMISTIC_WRITE);
> However, this behavior changes when running against trunk level code

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message