NamedQuery + LockModeType.NONE

[Howard Mak <hm...@antennasoftware.com>]

Hi,

I'm trying to get my NamedQuery to do SELECT *without* UPDLOCK with
OpenJPA 2.0.0.

https://issues.apache.org/jira/browse/OPENJPA-1604 claims that I cannot
use LockModeType.NONE with NamedQuery.

However,
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guid
e_locking_issues seems to contradict this with the following snippet:

<quote>
OpenJPAQuery q = em.createNamedQuery("findEmployeeById"); 
FetchPlan fp = q.getFetchPlan();
fp.setReadLockMode(LockModeType.NONE);
</quote>

Can anyone answer the following [or direct me to the right forum]?

Q1.	Is the JIRA claim [that LockModeType.NONE no longer works]
obsolete?

Q2.	What is the difference between
Query.getFetchPlan().setReadLocKMode(NONE) [specific to OpenJPA] +
Query.setLockMode(NONE) [available in JPA API]?

Q3.	Even when I do FetchPlan.setReadLockMode(NONE), I still get the
warning

	openjpa.MetaData <WARN   > Encountered a read lock level less
than LockModeType.READ when processing the NamedQuery annotation "..."
in class "...". Setting query lock level to LockModeType.READ

	Can we change AnnotationPersistenceMetaDataParser to make this
log suppressable?
	Perhaps introduce a compatibility flag that will respect
@NamedQuery(lockMode=NONE) as is?

Thanks for any help. 

- Howard

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. If you have received this email in error please delete it and notify the system administrator at administrator@antennasoftware.com

Re: NamedQuery + LockModeType.NONE

[Rick Curtis <cu...@gmail.com>]

If I remember correctly OPENJPA-1604 was opened for a compatibility issue
from 1.2.x to 2.0.0 when using the pessimistic lock manager.

My first question is, are you using the pessimistic lock manager? If so,
why? I'd recommend using the default lock manager (JPA2) and controlling
lock levels via NamedQuery lockMode, em.find(...) properties, etc.

hth,
Rick

On Mon, Jun 21, 2010 at 11:52 AM, Howard Mak <hm...@antennasoftware.com>wrote:

> Hi,
>
> I'm trying to get my NamedQuery to do SELECT *without* UPDLOCK with
> OpenJPA 2.0.0.
>
> https://issues.apache.org/jira/browse/OPENJPA-1604 claims that I cannot
> use LockModeType.NONE with NamedQuery.
>
> However,
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guid
> e_locking_issues seems to contradict this with the following snippet:
>
> <quote>
> OpenJPAQuery q = em.createNamedQuery("findEmployeeById");
> FetchPlan fp = q.getFetchPlan();
> fp.setReadLockMode(LockModeType.NONE);
> </quote>
>
> Can anyone answer the following [or direct me to the right forum]?
>
> Q1.     Is the JIRA claim [that LockModeType.NONE no longer works]
> obsolete?
>
> Q2.     What is the difference between
> Query.getFetchPlan().setReadLocKMode(NONE) [specific to OpenJPA] +
> Query.setLockMode(NONE) [available in JPA API]?
>
> Q3.     Even when I do FetchPlan.setReadLockMode(NONE), I still get the
> warning
>
>        openjpa.MetaData <WARN   > Encountered a read lock level less
> than LockModeType.READ when processing the NamedQuery annotation "..."
> in class "...". Setting query lock level to LockModeType.READ
>
>        Can we change AnnotationPersistenceMetaDataParser to make this
> log suppressable?
>        Perhaps introduce a compatibility flag that will respect
> @NamedQuery(lockMode=NONE) as is?
>
> Thanks for any help.
>
> - Howard
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the company.
> Finally, the recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any damage caused
> by any virus transmitted by this email. If you have received this email in
> error please delete it and notify the system administrator at
> administrator@antennasoftware.com
>