Re: why not an EntityExistsException was thrown?

[wanyna]

Surely you are right. The object to persist is just in the result of query. 
I'v made a mistake in my test case 2, I did not notice some relations.
Thanks.



Craig L Russell wrote:
> 
> Hi Wanyna,
> 
> Whenever you query for entities, the result entities are put into  
> your persistence context. So when you then try to persist another  
> entity with the same identity the provider finds the query result in  
> the persistence context and throws EntityExistsException.
> 
> Craig
> 
> On Apr 4, 2007, at 9:47 PM, wanyna wrote:
> 
>>
>> Your explaination is clearly if I only show my test case 1.
>> My test case 2, add a query before persist, then get  
>> EntityExistsException.
>> The result of  query hold some object no association with the  
>> object to
>> persist.
>> Why this time the object exists in persistence context?
>>
>>
>>
>> Craig L Russell wrote:
>>>
>>> If you look at the exception that is thrown from the database, it's a
>>> pretty general exception.
>>>
>>> "The statement was aborted because it would have caused a duplicate
>>> key  value in a unique or primary key constraint or unique index
>>> identified by  'SQL070403054930170' defined on 'BSC'."
>>>
>>> This might have been caused by a unique constraint, which would not
>>> be properly reported as EntityExistsException.
>>>
>>> Sadly, there is no standard SQL exception that specifically tells the
>>> provider (OpenJPA) that there was a primary key constraint violation.
>>> And you might also note that every database has its own way to report
>>> exceptions like this.
>>>
>>> What the EntityExistsException does is to report that there is
>>> already an entity with the same primary key in the persistence
>>> context. It doesn't report that there was a problem writing the
>>> entity to the database.
>>>
>>> If you're looking for better error reporting you can flush as part of
>>> the application-level persist operation. That way your application
>>> can catch a persistence exception that is caused either by persist or
>>> flush and report it as a "problem persisting entity" to your caller.
>>>
>>> But there is a down side to this. If you flush immediately after
>>> persist, the provider cannot optimize for performance. So it's a
>>> tradeoff that you need to make in your application.
>>>
>>> If you're keen on "fixing" this situation, I'd encourage you to
>>> volunteer to look at the databases and how they report unique and
>>> primary key constraint violations and see if it's possible to parse
>>> the sql code and report string to positively identify a primary key
>>> constraint violation.
>>>
>>> Craig
>>>
>>> On Apr 3, 2007, at 9:42 PM, wanyna wrote:
>>>

 I can't find EntityExistsException nested in RollbackExceptions.
 http://www.nabble.com/file/7646/exception.jpg

 Will exception mechanism be planned to improve?
 I think it's very important.


 Patrick Linskey wrote:
>
> Cool -- that explains it then.
>
> EM.commit() must throw RollbackExceptions (and
> org.apache.openjpa.persistence.RollbackException extends
> javax.persistence.RollbackException) when the transaction is
> rolled back
> during the course of the commit.
>
> If you get the nested exception from the RollbackException, I bet
> that
> it's instanceof EntityExistsException.
>
> Clearly, however, something is wonky with our exception printing
> algorithm.
>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
> ___ 
> __
> __
> Notice:  This email message, together with any attachments, may
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
>
>> -Original Message-
>> From: wanyna [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, April 03, 2007 8:49 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: RE: why not an EntityExistsException was thrown?
>>
>>
>> actual class of the exception:
>> class org.apache.openjpa.persistence.RollbackException
>> <2|true|0.9.7-incubating-SNAPSHOT>
>> org.apache.openjpa.persistence.RollbackException: The
>> transaction has been
>> rolled back.  See the nested exceptions for details on the errors
>> that
>> occurred.
>>  at
>> org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
>> ManagerImpl.java:417)
>>  at test.Main.main(Main.java:82)
>> Caused by: <0|true|0.9.7-incubating-SNAPSHOT>
>> org.apache.openjpa.persistence.Persis

Re: Query returning 2 entities w/1-1 relationship gets either openjpa.persistence.ArgumentException: Address with the same id already exists in the L1 cache. or returns [Address, Address] instead of [

[Marc Prud'hommeaux]

George-

I'm not sure the exact problem (your model looks OK to me at first  
glance), but FTR, I just tried a simple test with a query that  
returns "ob, ob.someOneToOne", and it returned the expected values  
(in this case, a  
org.apache.openjpa.persistence.models.company.basic.Customer and  
org.apache.openjpa.persistence.models.company.basic.Address  
instance). So projecting over relations isn't fundamentally broken,  
although there may very well be a bug in there somewhere.


Can you try to refine down your test case so it is just two simple  
entities and a test case that exhibits the bug? That will make it  
easier to isolate the cause. Opening a JIRA issue while you are at it  
would be useful :)






On Apr 5, 2007, at 6:05 PM, George Hongell wrote:


Query returning 2 entities w/1-1 relationship gets either

openjpa.persistence.ArgumentException : Address with the same id  
already exists in the L1 cache. or returns [Address, Address]  
instead of [Winery, Address]

depending on select order

if

_em.find(Winery.class,parm1) is not executed before  
query.getResultList().
"SELECT r,r.address" returns [Address, Address] and "SELECT  
r.address,r" gets same Address id already exists in the L1 cache


Run main program in BugWineryTest class in attached application to  
reproduce Error.
-- 
---


701 bugwineTour TRACE [main] openjpa.jdbc.SQL - 1652187770> [0 ms] spent


1171 bugwineTour TRACE [main] openjpa.jdbc.SQL - conn 1652187770> executing prepstmnt 887502054 SELECT t1.phone,  
t1.version, t1.city, t1.state, t1.street, t1.zip, t0.wineryid FROM  
bugWinery t0 LEFT OUTER JOIN bugAddress t1 ON t0.address_phone =  
t1.phone WHERE (t0.wineryid = ?) [params=(int) 1]


1171 bugwineTour TRACE [main] openjpa.jdbc.SQL - conn 1652187770> [0 ms] spent


<4|false|0.9.7-incubating-SNAPSHOT>

org.apache.openjpa.persistence.ArgumentException: Cannot load  
object with id "1". Instance "  
com.ibm.websphere.ejb3sample.winetour.bug.Address-1" with the same  
id already exists in the L1 cache. This can occur when you assign  
an existing id to a new instance, and before flushing attempt to  
load the existing instance for that id.

FailedObject: com.ibm.websphere.ejb3sample.winetour.bug.Address-1

at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.add(

BrokerImpl.java:4418)
at org.apache.openjpa.kernel.BrokerImpl.setStateManager(

BrokerImpl.java:3773)
at org.apache.openjpa.kernel.StateManagerImpl.initialize(

StateManagerImpl.java:297)
at org.apache.openjpa.kernel.StateManagerImpl.initialize(

StateManagerImpl.java:258)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(

JDBCStoreManager.java:327 )
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(

JDBCStoreManager.java:252)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(

DelegatingStoreManager.java:108 )
at org.apache.openjpa.kernel.ROPStoreManager.initialize(

ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize(

BrokerImpl.java:873)
at org.apache.openjpa.kernel.BrokerImpl.find(

BrokerImpl.java:831)
at org.apache.openjpa.kernel.BrokerImpl.find(

BrokerImpl.java:753)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(

JDBCStoreManager.java:773)
at org.apache.openjpa.jdbc.sql.AbstractResult.load(

AbstractResult.java:254)
at org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(

SelectImpl.java:2115)
at org.apache.openjpa.jdbc.kernel.exps.PCPath.load(

PCPath.java:684)
at org.apache.openjpa.jdbc.kernel.exps.PCPath.load(

PCPath.java:672)
at  
org.apache.openjpa.jdbc.kernel.ProjectionResultObjectProvider.getResul 
tObject(


ProjectionResultObjectProvider.java:73 )
at org.apache.openjpa.lib.rop.EagerResultList.(

EagerResultList.java:33)
at org.apache.openjpa.kernel.QueryImpl.toResult(

QueryImpl.java:1214)
at org.apache.openjpa.kernel.QueryImpl.execute(

QueryImpl.java:981)
at org.apache.openjpa.kernel.QueryImpl.execute(

QueryImpl.java:834)
at org.apache.openjpa.kernel.QueryImpl.execute(

QueryImpl.java:765)
at org.apache.openjpa.kernel.DelegatingQuery.execute(

DelegatingQuery.java:520)
at org.apache.openjpa.persistence.QueryImpl.execute(

QueryImpl.java:224)
at org.apache.openjpa.persistence.QueryImpl.getResultList(

QueryImpl.java:264)
at  
com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.test_1_1relati 
onshipQuery_Winery_address(


BugWineryTest.java:434 )
at com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(

BugWineryTest.java:90)
<1_1BugWineryTest.zip>

RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Patrick Linskey]

> Why don't you integrate your patch and then we will rerun our tests to
> make sure the function works as we had originally intended.

I just did this in r525997. I also added a couple of test cases.
TestSelectForUpdateOverride asserts that the DBDictionary is called with
the appropriate forUpdate setting based on fetch configuration and
transaction data; TestIsolationLevelOverride tests the behavior of the
new JDBCFetchPlan.setIsolationLevel() API.

I committed this on the assumption that Abe will agree that since a
number of databases support this concept, it makes sense to have a
common API for it.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: David Wisneski [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 05, 2007 11:35 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock 
> syntax WITH  USE AND KEEP UPDATE LOCKS
> 
> Patrick,
> 
> We were unaware that fetch plan properties could be set as Hints.  Now
> that we look at the code we see this,  but we did not find this when
> we read the OpenJPA documentation.  The only hint we found in the
> documentation was the OracleSelectHint and so our design was based on
> how OracleSelectHint was implemented.  OracleSelectHint is not
> implemented as a FetchPlan property.
> 
> Why don't you integrate your patch and then we will rerun our tests to
> make sure the function works as we had originally intended.
> 
> 
> On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> >[ 
> https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atl
assian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1248704
6 ]
> >
> > Patrick Linskey commented on OPENJPA-182:
> > -
> >
> > > > Hopefully, this will be useful for applications where 
> there are "hot" tables
> > > > that require pessimistic locking even though the rest 
> of the application
> > > > does better with optimistic.
> > >
> > > That's what our lock levels and lock APIs are for. I'm 
> still not clear on what this is
> > > adding to the mix for most DBs.
> >
> > Not really -- the lock levels allow the user to configure 
> how locking should happen, not what the isolation level 
> should be for the locks.
> >
> > I don't know about what levels of support non-DB2 databases 
> have for per-query isolation level configuration. Does anyone 
> have any experience with this in other databases?
> >
> > Oh, and regardless, we should change the base DBDictionary 
> to throw an exception if this FetchPlan setting is set but 
> not serviceable.
> >
> > One thing that we should test: I'm not convinced that the 
> lock level override in the DB2Dictionary code is necessary. 
> It's possible that the LockManager will already take into 
> account the current JDBCFetchConfiguration's lock level 
> settings when specifying the forUpdate setting for the 
> toSelect() clause. Some test cases will make it easy to 
> figure out the answer to this question.
> >
> > > db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> > > --
> > >
> > > Key: OPENJPA-182
> > > URL: 
> https://issues.apache.org/jira/browse/OPENJPA-182
> > > Project: OpenJPA
> > >  Issue Type: New Feature
> > >  Components: jdbc
> > > Environment: db2 database driver for zOS, AS400, 
> Unix, Windows, Linux
> > >Reporter: David Wisneski
> > > Assigned To: David Wisneski
> > > Attachments: OPENJPA-182.patch, openJPA182.patch
> > >
> > >
> > > A while back we changed the syntax of update locking from 
> FOR UPDATE OF  to  WITH RS USE AND KEEP UPDATE LOCKS.   
> Additional changes are required because
> > > 1.  if isolation=serializable is configured, then the 
> syntax should be  WITH RR USE AND KEEP UDPATE LOCKS
> > > 2.  when using DB2/400 on iSeries machines, the syntax is 
> WITH RS USE AND KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP 
> EXCLUSIVE LOCKS because DB2/400 only supports read or exclusive locks.
> > > 3.  DB2 supports both a FETCH FIRST  ROWS and update 
> LOCKS clauses.
> > > So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to 
> append the correct LOCKS syntax depending on vendor, release 
> and isolation level.
> >
> > --
> > This message is

[jira] Updated: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Ritika Maheshwari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ritika Maheshwari updated OPENJPA-182:
--

Attachment: openjpa182TestCase.jar

Here is a jar containing the 2 entities on whcih I run my testcases.

em.getTransaction().begin()
Query qryA = em.createQuery("select d from DeptBean2 d where d.no = 1");
qryA.setHint("openjpa.hint.updateClause",true);
qryA.setHint("openjpa.hint.isolationLevel", "serializable");
List rsA = qryA.getResultList();

The SQL Output looks like

13109  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 694036830 SELECT t0.no, t1.empid, t2.no, t2.mgr_empid, 
t2.cdname, t1.ceemp_ts, t1.cehireDate, t1.ceismanager, t1.cename, t1.cesalary, 
t0.cdname FROM deptab2 t0 LEFT OUTER JOIN emptab2 t1 ON t0.mgr_empid = t1.empid 
LEFT OUTER JOIN deptab2 t2 ON t1.dept_no = t2.no WHERE (CAST(t0.no AS BIGINT) = 
CAST(? AS BIGINT))  WITH RR USE AND KEEP UPDATE LOCKS  [params=(long) 1]
13119  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
[10 ms] spent
27420  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 2102295886 SELECT t0.empid, t1.no, t2.empid, t2.dept_no, 
t2.ceemp_ts, t2.cehireDate, t2.ceismanager, t2.cename, t2.cesalary, t1.cdname, 
t0.ceemp_ts, t0.cehireDate, t0.ceismanager, t0.cename, t0.cesalary FROM emptab2 
t0 LEFT OUTER JOIN deptab2 t1 ON t0.dept_no = t1.no LEFT OUTER JOIN emptab2 t2 
ON t1.mgr_empid = t2.empid WHERE t0.dept_no = ?  WITH RR USE AND KEEP UPDATE 
LOCKS  [params=(int) 1]
27430  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
[10 ms] spent

 Query qryB = em.createQuery("select e from EmpBean2 e where e.empid = 1");
  qryB.setHint("openjpa.hint.updateClause",true);
   qryB.setHint("openjpa.hint.isolationLevel", "read-uncommitted");
List rsB = qryB.getResultList();

The SQL Output looks like


47969  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 1530944320 SELECT t0.empid, t1.no, t2.empid, t2.dept_no, 
t2.ceemp_ts, t2.cehireDate, t2.ceismanager, t2.cename, t2.cesalary, t1.cdname, 
t0.ceemp_ts, t0.cehireDate, t0.ceismanager, t0.cename, t0.cesalary FROM emptab2 
t0 LEFT OUTER JOIN deptab2 t1 ON t0.dept_no = t1.no LEFT OUTER JOIN emptab2 t2 
ON t1.mgr_empid = t2.empid WHERE (CAST(t0.empid AS BIGINT) = CAST(? AS BIGINT)) 
 WITH RS USE AND KEEP UPDATE LOCKS  [params=(long) 1]
47969  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
[0 ms] spent

Query qryC = em.createQuery("select d from DeptBean2 d where d.no = 1");
 DeptBean2 deptC  = (DeptBean2)qryC.getSingleResult();

The SQL Out put is 

72695  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 742009914 SELECT t0.no, t1.empid, t2.no, t2.mgr_empid, 
t2.cdname, t1.ceemp_ts, t1.cehireDate, t1.ceismanager, t1.cename, t1.cesalary, 
t0.cdname FROM deptab2 t0 LEFT OUTER JOIN emptab2 t1 ON t0.mgr_empid = t1.empid 
LEFT OUTER JOIN deptab2 t2 ON t1.dept_no = t2.no WHERE (CAST(t0.no AS BIGINT) = 
CAST(? AS BIGINT))  FOR READ ONLY  optimize for 1 row [params=(long) 1]
72695  dwtest  TRACE  [main] openjpa.jdbc.SQL -  
[0 ms] spent

In my persistence.xml I  had the following properties

   


Essentially if  we are running against DB2 8.2 or Later then if update lock is 
true then for all the isolation levels other than "serializable"  WITH RS USE 
AND KEEP UPDATE LOCKS clause is appended to the query.In case of "serializable" 
isolation level "WITH RR USE AND KEEP UPDATE LOCK" is appended.

If the updateLock is false then FOR READ ONLY clause is appended to all queries.




> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch, 
> openjpa182TestCase.jar
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Patrick Linskey (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487099
 ] 

Patrick Linskey commented on OPENJPA-182:
-

Between Ritika's SQLServer email on the dev list and Mike's Sybase research, it 
sounds like this feature is supported by enough databases that I think it's 
useful to expose as an API, rather than just a DB2-specific hint.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

Re: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Ritika Maheshwari]

I think I mentioned the wrong place but in SQLServer the isolation level can
be specified as a table hint. The Table hint specifies that the query
optimizer use a table scan, one or more indexes, or a locking method with
this table or view and for this SELECT, INSERT, UPDATE, or DELETE statement.
The table hint is specified in the FROM Clause. The Table hint syntax is


[image: Syntax]Syntax

 ::=
[ NOEXPAND ] {
   INDEX ( index_val [ ,...n ] )
 | FASTFIRSTROW
 | HOLDLOCK
 | NOLOCK
 | NOWAIT
 | PAGLOCK
 | READCOMMITTED
 | READCOMMITTEDLOCK
 | READPAST
 | READUNCOMMITTED
 | REPEATABLEREAD
 | ROWLOCK
 | SERIALIZABLE
 | TABLOCK
 | TABLOCKX
 | UPDLOCK
 | XLOCK
}




On 4/5/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:


But both of those settings are per-transaction things, not per-query
things. The DB2 isolation level syntax differs in that it is part of the
SQL statement issued, rather than a separate configuration for the
transaction-wide isolation level.

Theoretically, the JDBC transaction-level isolation level settings that
OpenJPA performs should be equivalent to these SET TRANSACTION SQL
statements, right?

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

> -Original Message-
> From: Ritika Maheshwari [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 05, 2007 1:18 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock
> syntax WITH  USE AND KEEP UPDATE LOCKS
>
> Informix has the following
>
>  SET TRANSACTION
>  m.ibm.sqls.doc/sqls02.htm#ToC_987>
> Use
> the SET TRANSACTION statement to define the isolation level
> and to specify
> whether the access mode of a transaction is read-only or read-write.
> Syntax
>
> [image: Read syntax diagram][image: Skip visual syntax diagram]
>  m.ibm.sqls.doc/sqls815.htm?resultof=%22%74%72%61%6e%73%61%63%7
4%69%6f%6e%22%20%22%74%72%61%6e%73%61%63%74%22%20%22%69%73%6f%>
6c%61%74%69%6f%6e%22%20%22%69%73%6f%6c%22%20#skipsyn-276>>>-SET
> TRANSACTION-->
>
>.-,.
>V(1)   |
> >++-READ WRITE-++-+><
>  |'-READ ONLY--'|
>  |  (1) |
>  'ISOLATION LEVEL--+-READ COMMITTED---+-'
>+-REPEATABLE READ--+
>+-SERIALIZABLE-+
>'-READ UNCOMMITTED-'
>
>
>
>
> SQLServer has the following
>
> [image:
> Syntax]Syntax
>
> SET TRANSACTION ISOLATION LEVEL
> { READ UNCOMMITTED
> | READ COMMITTED
> | REPEATABLE READ
> | SNAPSHOT
> | SERIALIZABLE
> }
> [ ; ]
>
> On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> >
> >[
> >
> https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atl
assian.jira.plugin.system.issuetabpanels:comment->
tabpanel#action_12487086]
> >
> > Patrick Linskey commented on OPENJPA-182:
> > -
> >
> > > > I know that Oracle allows you to add a FOR UPDATE clause
> > > > to a query, and this affects the results of that query. In Sun
> > > > appserver CMP we use this to set exclusive locks on rows
> > > > where we want pessimistic locking behavior just for
> certain tables.
> > >
> > > Again, this is exactly what our existing lock levels and APIs do.
> >
> > The current patches in this issue encompass two separate bits of
> > functionality:
> >
> > 1. an update-override setting. (In the context of my patch, I'm not
> > convinced that this is necessary, since I suspect that the
> code that calls
> > toSelect() might set the forUpdate boolean based on the
> values in the
> > JDBCFetchConfiguration anyways.)
> >
> > 2. an isolation-override setting.
> >
> > Currently, this patch implements all of this only in the
> DB2Dictionary. As
> > of right now, the first feature is something that is useful
> for all sorts of
> > databases, via syntax like Oracle's SELECT ... FOR UPDATE.
> However, we only
> > know how to implement the second feature for DB2, and not
> for any other
> > database. In Oracle, "ALTER SESSIO

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Michael Dick (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487098
 ] 

Michael Dick commented on OPENJPA-182:
--

I have no practical experience with Sybase, but I did find this in their 
TransactSQL user's guide :

"Changing the isolation level for a query

You can change the isolation level for a query by using the at isolation clause 
with the select or readtext statements. The at isolation clause supports 
isolation levels 0, 1, and 3. It does not support isolation level 2. The read 
uncommitted, read committed, and serializable options of at isolation represent 
isolation levels as listed below:

at isolation option Isolation level
read uncommited  0
read committed 1
serializable3

For example, the following two statements query the same table at isolation 
levels 0 and 3, respectively:

select *
from titles
at isolation read uncommitted

select *
from titles
at isolation serializable"

There's more information online here: 
http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/53911;hf=0



> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

Re: Using query hints for mapping extensions in orm.xml

[Russell Parry]

Has there been any progress on this issue?  I just came across a case  
today where I'd like this functionality and some searching turned up  
this thread.  I don't see anything on this subject that is more  
recent than the email below, but I'm not sure that I'm not just  
looking in the wrong places.


Thanks.



On Jan 25, 2007, at 1:07 PM, Patrick Linskey wrote:


... and option 4 is:

- user creates an orm.xml using the Sun XSD. This contains only
JPA-standard options, and is thus portable.

- user also creates an openjpa-orm.xml file using the OpenJPA XSD as
discussed already (or potentially a new OpenJPA-only XSD). This  
contains

only OpenJPA extension options. Again, the application is therefore
portable -- other vendors will clearly ignore the openjpa-orm.xsd  
file.


-Patrick

--
Patrick Linskey
BEA Systems, Inc.

__ 
_
Notice:  This email message, together with any attachments, may  
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and   
affiliated
entities,  that may be confidential,  proprietary,  copyrighted   
and/or
legally privileged, and is intended solely for the use of the  
individual
or entity named in this message. If you are not the intended  
recipient,
and have received this message in error, please immediately return  
this

by email and then delete it.


-Original Message-
From: Albert Lee [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 25, 2007 9:26 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Using query hints for mapping extensions in orm.xml

Let's put this into a more concrete terms:

Given:
1) Existing JPA orm schema in
  http://java.sun.com/xml/ns/persistence/orm_1_0.xsd

2) OpenJPA supports its version of the orm schema in

http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa
_orm_1_0.xsd
   Note: we need to find a more permanent home for this
schema other
than putting it in incubator.apache.org. Suggestions?

3) xml name space for both schema are:

xmlns="http://java.sun.com/xml/ns/persistence/orm";
 xmlns:openjpa="http://java.sun.com/xml/ns/persistence/orm";
   Note: Both schema MUST be in the same name space due to schma
redefine restriction.

Use cases:
1) application specifies orm_1_0.xsd in the orm.xml
- portable to other providers
- no openjpa specific functions allow.

2) application specifies openjpa_orm_1_0.xsd in orm.xml
- only "guarantee" to work with openjpa provider.
- openjpa functions must be specified according to openjpa orm
additional schema.
- Can use the combination of persistence.xml  and
orm.xml
stanza to enforce
the orm must be applied using openjpa provider.

  persistence.xml
 
 
 
org.apache.openjpa.persistence.PersistenceProviderImpl

META-INF/openjpa_orm.xml
..
  openjpa_orm.xml
 http://java.sun.com/xml/ns/persistence/orm

http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa
_orm_1_0.xsd">
 

3) No schema is specified in the orm.xml (least desirable option)
- openjpa functions may be added to orm.xml. OpenJPA
tolerates this
option
- There is no validation on the stanza, hence may be
problematic in
processing/handling of the stanza.
- No guarantee this will work in other providers.
- But this option is the least restrictive in orm usage

All three options are available for use by an application, in  
order of

compliance and portability preferences.

Albert Lee.

On 1/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:


Firstly, thanks for putting this together.

I don't think that portability is a huge problem. I agree

with the three

scenarios that Albert mentioned, but I think that we can refine #1:


1) if an application wants to be fully portable between

providers, the

standard orm.xsd must be specified. This will inhibit the use
of openjpa
features.


I would revise this as follows:

1) if an application wants to be fully portable between

providers, the

standard orm.xsd must be specified. This will inhibit the

use of OpenJPA

features in that file, so a parallel openjpa-orm.xml file

must be used

which conforms to the OpenJPA XSD and adds the additional

information.


We could even create a second XSD for that situation that

allows only

OpenJPA content to help prevent people from putting

conflicting stanzas

in the two files.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.



__
_

Notice:  This email message, together with any attachments,

may contain

information  of  BEA Systems,  Inc.,  its subsidiaries  and

 affiliated

entities,  that may be confidential,  proprietary,

copyrighted  and/or

legally privileged, and is intended solely for the use of

the individual

or entity named in this message. If you are not the

intended recipient,

and have

[jira] Created: (OPENJPA-205) JPA2 Follow-Up

[Patrick Linskey (JIRA)]

JPA2 Follow-Up
--

 Key: OPENJPA-205
 URL: https://issues.apache.org/jira/browse/OPENJPA-205
 Project: OpenJPA
  Issue Type: Improvement
  Components: jpa
Reporter: Patrick Linskey


This is an umbrella issue for all the issues that we should be tracking for the 
JPA2 specification. As issues are incorporated into the JPA2 specification or 
otherwise dismissed by the expert group, they may be removed from this umbrella 
issue as well, to reduce the number of issues in this umbrella.

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

Re: annotations / tags in JIRA?

[Marc Prud'hommeaux]

Patrick-

I don't know about adding keywords or anything like that, but you  
could always create a new "JPA2 issues" JIRA issue, and then "link"  
the issues you want to follow-up to it. There are a variety of link  
types ... you could use the "is related to" link.




On Apr 5, 2007, at 1:31 PM, Patrick Linskey wrote:


Hi,

Is it possible to annotate issues in JIRA with some sort of structured
or semi-structured tag? I'd like to be able to mark OPENJPA-204 so  
that
we can come back to it later when working on the next JPA  
specification

version. I guess I could clone the issue and either make a new issue
type or a new component, but it seems like it'd be convenient to just
mark it as "JPA2-followup" or something like that.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

__ 
_
Notice:  This email message, together with any attachments, may  
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and   
affiliated
entities,  that may be confidential,  proprietary,  copyrighted   
and/or
legally privileged, and is intended solely for the use of the  
individual
or entity named in this message. If you are not the intended  
recipient,
and have received this message in error, please immediately return  
this

by email and then delete it.

Notice:  This email message, together with any attachments, may  
contain information  of  BEA Systems,  Inc.,  its subsidiaries   
and  affiliated entities,  that may be confidential,  proprietary,   
copyrighted  and/or legally privileged, and is intended solely for  
the use of the individual or entity named in this message. If you  
are not the intended recipient, and have received this message in  
error, please immediately return this by email and then delete it.

annotations / tags in JIRA?

[Patrick Linskey]

Hi,

Is it possible to annotate issues in JIRA with some sort of structured
or semi-structured tag? I'd like to be able to mark OPENJPA-204 so that
we can come back to it later when working on the next JPA specification
version. I guess I could clone the issue and either make a new issue
type or a new component, but it seems like it'd be convenient to just
mark it as "JPA2-followup" or something like that.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Patrick Linskey]

But both of those settings are per-transaction things, not per-query
things. The DB2 isolation level syntax differs in that it is part of the
SQL statement issued, rather than a separate configuration for the
transaction-wide isolation level.

Theoretically, the JDBC transaction-level isolation level settings that
OpenJPA performs should be equivalent to these SET TRANSACTION SQL
statements, right?

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Ritika Maheshwari [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 05, 2007 1:18 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock 
> syntax WITH  USE AND KEEP UPDATE LOCKS
> 
> Informix has the following
> 
>  SET TRANSACTION
>  m.ibm.sqls.doc/sqls02.htm#ToC_987>
> Use
> the SET TRANSACTION statement to define the isolation level 
> and to specify
> whether the access mode of a transaction is read-only or read-write.
> Syntax
> 
> [image: Read syntax diagram][image: Skip visual syntax diagram]
>  m.ibm.sqls.doc/sqls815.htm?resultof=%22%74%72%61%6e%73%61%63%7
4%69%6f%6e%22%20%22%74%72%61%6e%73%61%63%74%22%20%22%69%73%6f%>
6c%61%74%69%6f%6e%22%20%22%69%73%6f%6c%22%20#skipsyn-276>>>-SET
> TRANSACTION-->
> 
>.-,.
>V(1)   |
> >++-READ WRITE-++-+><
>  |'-READ ONLY--'|
>  |  (1) |
>  'ISOLATION LEVEL--+-READ COMMITTED---+-'
>+-REPEATABLE READ--+
>+-SERIALIZABLE-+
>'-READ UNCOMMITTED-'
> 
> 
> 
> 
> SQLServer has the following
> 
> [image: 
> Syntax]Syntax
> 
> SET TRANSACTION ISOLATION LEVEL
> { READ UNCOMMITTED
> | READ COMMITTED
> | REPEATABLE READ
> | SNAPSHOT
> | SERIALIZABLE
> }
> [ ; ]
> 
> On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> >
> >[
> > 
> https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atl
assian.jira.plugin.system.issuetabpanels:comment->
tabpanel#action_12487086]
> >
> > Patrick Linskey commented on OPENJPA-182:
> > -
> >
> > > > I know that Oracle allows you to add a FOR UPDATE clause
> > > > to a query, and this affects the results of that query. In Sun
> > > > appserver CMP we use this to set exclusive locks on rows
> > > > where we want pessimistic locking behavior just for 
> certain tables.
> > >
> > > Again, this is exactly what our existing lock levels and APIs do.
> >
> > The current patches in this issue encompass two separate bits of
> > functionality:
> >
> > 1. an update-override setting. (In the context of my patch, I'm not
> > convinced that this is necessary, since I suspect that the 
> code that calls
> > toSelect() might set the forUpdate boolean based on the 
> values in the
> > JDBCFetchConfiguration anyways.)
> >
> > 2. an isolation-override setting.
> >
> > Currently, this patch implements all of this only in the 
> DB2Dictionary. As
> > of right now, the first feature is something that is useful 
> for all sorts of
> > databases, via syntax like Oracle's SELECT ... FOR UPDATE. 
> However, we only
> > know how to implement the second feature for DB2, and not 
> for any other
> > database. In Oracle, "ALTER SESSION" can be used to change 
> the isolation
> > level of a given session, but I'm not sure of the semantics of this
> > operation. I believe that Abe's question is: Do other 
> databases (Sybase?
> > Derby?) also have semantics for changing the isolation 
> level of a particular
> > query?
> >
> > > db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> > > --
> > >
> > > Key: OPENJPA-182
> > > URL: 
> https://issues.apache.org/jira/browse/OPENJPA-182
> > > Project: OpenJPA
> > >  Issue Type: New Feature
> > >  Components: jdbc
> > > Environment: db2 database driver for zOS, AS400, 
> Unix, Windows,
> > Linux
> > >

Re: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Ritika Maheshwari]

Informix has the following

SET TRANSACTION

Use
the SET TRANSACTION statement to define the isolation level and to specify
whether the access mode of a transaction is read-only or read-write.
Syntax

[image: Read syntax diagram][image: Skip visual syntax diagram]
>>-SET
TRANSACTION-->

  .-,.
  V(1)   |

++-READ WRITE-++-+><

|'-READ ONLY--'|
|  (1) |
'ISOLATION LEVEL--+-READ COMMITTED---+-'
  +-REPEATABLE READ--+
  +-SERIALIZABLE-+
  '-READ UNCOMMITTED-'




SQLServer has the following

[image: Syntax]Syntax

SET TRANSACTION ISOLATION LEVEL
   { READ UNCOMMITTED
   | READ COMMITTED
   | REPEATABLE READ
   | SNAPSHOT
   | SERIALIZABLE
   }
[ ; ]

On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:



   [
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487086]

Patrick Linskey commented on OPENJPA-182:
-

> > I know that Oracle allows you to add a FOR UPDATE clause
> > to a query, and this affects the results of that query. In Sun
> > appserver CMP we use this to set exclusive locks on rows
> > where we want pessimistic locking behavior just for certain tables.
>
> Again, this is exactly what our existing lock levels and APIs do.

The current patches in this issue encompass two separate bits of
functionality:

1. an update-override setting. (In the context of my patch, I'm not
convinced that this is necessary, since I suspect that the code that calls
toSelect() might set the forUpdate boolean based on the values in the
JDBCFetchConfiguration anyways.)

2. an isolation-override setting.

Currently, this patch implements all of this only in the DB2Dictionary. As
of right now, the first feature is something that is useful for all sorts of
databases, via syntax like Oracle's SELECT ... FOR UPDATE. However, we only
know how to implement the second feature for DB2, and not for any other
database. In Oracle, "ALTER SESSION" can be used to change the isolation
level of a given session, but I'm not sure of the semantics of this
operation. I believe that Abe's question is: Do other databases (Sybase?
Derby?) also have semantics for changing the isolation level of a particular
query?

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows,
Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE
OF  to  WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required
because
> 1.  if isolation=serializable is configured, then the syntax should
be  WITH RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE
AND KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because
DB2/400 only supports read or exclusive locks.
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the
AbstractDB2Dictionary class and change the DB2Dictionary to append the
correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Resolved: (OPENJPA-204) Nesting of Emebedded in Embeddable element

[Patrick Linskey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OPENJPA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-204.
-

Resolution: Won't Fix

This is a limitation of the JPA spec. From section 9.1.34: 

Only Basic, Column, Lob, Temporal, and Enumerated mapping annotations may 
portably be used to map the persistent fields or properties of classes 
annotated as Embeddable.

OpenJPA supports embedded fields in embeddable instances, as well as various 
other usages of embedded things, but those are extensions to the spec. Due to 
OPENJPA-125, you can only configure nested embeddeds via annotations currently.

Marking this as WNF, although in some ways it might be better closed as a 
duplicate of OPENJPA-125, since once we resolve OPENJPA-125, there will be a 
way to do this in XML (albeit not the spec-defined XML).

Note that the JPA spec team defines the orm.xsd; OpenJPA is just an 
implementation of that spec. So, we can't change the orm.xsd. I believe, 
however, that this is an issue that the JPA 2 spec team will probably consider.

> Nesting of Emebedded in Embeddable element
> --
>
> Key: OPENJPA-204
> URL: https://issues.apache.org/jira/browse/OPENJPA-204
> Project: OpenJPA
>  Issue Type: Bug
>  Components: jpa
>Affects Versions: 0.9.6
>Reporter: sharath.h
>
> Hi,
>  
> In orm_1_0.xsd or orm-xsd.rsrc files under the  name="embeddable-attributes"> the  type="orm:embedded"minOccurs="0" maxOccurs="unbounded"/> is not present.
>  
> Please let me know if there is any valid reason behind it.Was the embedded 
> element in embeddable-attributes was accidently missed out?
>  
> I faced the issue when i tried the example something like as shown below:
>  
> class A
> {
>   int id;
>   B objB;
>   
> }
>  
> class B
> {
>   String str1;
>   Date d;
>   C objC;
> }
>  
> class C
> {
>String str2;
> }
>  
> I wanted to persist object A into a single table by having object B as 
> embedded and object B inturn having object C as embedded.
> My corresponding orm mapping file is as shown below:
>  
> 
> http://java.sun.com/xml/ns/persistence/orm"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm orm_1_0.xsd" 
> version="1.0">
>  
> 
> 
>  
> 
> 
>   
> 
> 
> 
>  
>   
>   
> 
>
>  
> 
>
> 
> 
> 
>   
>  
> 
>
>  
> 
> 
>  
> This was not possible due to orm schema restriction.
>  
>  
>  
> Thanks,
> Regards,
> Sharath.H

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

[jira] Created: (OPENJPA-204) Nesting of Emebedded in Embeddable element

[sharath.h (JIRA)]

Nesting of Emebedded in Embeddable element
--

 Key: OPENJPA-204
 URL: https://issues.apache.org/jira/browse/OPENJPA-204
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.6
Reporter: sharath.h


Hi,
 
In orm_1_0.xsd or orm-xsd.rsrc files under the  the  is not present.
 
Please let me know if there is any valid reason behind it.Was the embedded 
element in embeddable-attributes was accidently missed out?
 
I faced the issue when i tried the example something like as shown below:
 
class A
{
  int id;
  B objB;
  
}
 
class B
{
  String str1;
  Date d;
  C objC;
}
 
class C
{
   String str2;
}
 
I wanted to persist object A into a single table by having object B as embedded 
and object B inturn having object C as embedded.
My corresponding orm mapping file is as shown below:
 

http://java.sun.com/xml/ns/persistence/orm"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm orm_1_0.xsd" 
version="1.0">
 


 


  



 
  
  

   
 

   




  
 

   
 



 
This was not possible due to orm schema restriction.
 
 
 
Thanks,
Regards,
Sharath.H

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Patrick Linskey (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487086
 ] 

Patrick Linskey commented on OPENJPA-182:
-

> > I know that Oracle allows you to add a FOR UPDATE clause 
> > to a query, and this affects the results of that query. In Sun 
> > appserver CMP we use this to set exclusive locks on rows 
> > where we want pessimistic locking behavior just for certain tables.
> 
> Again, this is exactly what our existing lock levels and APIs do.

The current patches in this issue encompass two separate bits of functionality:

1. an update-override setting. (In the context of my patch, I'm not convinced 
that this is necessary, since I suspect that the code that calls toSelect() 
might set the forUpdate boolean based on the values in the 
JDBCFetchConfiguration anyways.)

2. an isolation-override setting.

Currently, this patch implements all of this only in the DB2Dictionary. As of 
right now, the first feature is something that is useful for all sorts of 
databases, via syntax like Oracle's SELECT ... FOR UPDATE. However, we only 
know how to implement the second feature for DB2, and not for any other 
database. In Oracle, "ALTER SESSION" can be used to change the isolation level 
of a given session, but I'm not sure of the semantics of this operation. I 
believe that Abe's question is: Do other databases (Sybase? Derby?) also have 
semantics for changing the isolation level of a particular query?

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Abe White (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487085
 ] 

Abe White commented on OPENJPA-182:
---

>  I know that Oracle allows you to add a FOR UPDATE clause to a query, and 
> this affects the results of that query. In Sun appserver CMP we use this to 
> set exclusive locks on rows where we want pessimistic locking behavior just 
> for certain tables.

Again, this is exactly what our existing lock levels and APIs do.  

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Craig Russell (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487082
 ] 

Craig Russell commented on OPENJPA-182:
---

I know that Oracle allows you to add a FOR UPDATE clause to a query, and this 
affects the results of that query. In Sun appserver CMP we use this to set 
exclusive locks on rows where we want pessimistic locking behavior just for 
certain tables.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Patrick Linskey]

> We were unaware that fetch plan properties could be set as Hints.  Now
> that we look at the code we see this,  but we did not find this when
> we read the OpenJPA documentation. 

Yeah, it seems like we should probably do some documentation of some of
these newer configuration options.

> The only hint we found in the
> documentation was the OracleSelectHint and so our design was based on
> how OracleSelectHint was implemented.  OracleSelectHint is not
> implemented as a FetchPlan property.

FWIW, OracleSelectHint is implemented as it is because it's a proper
hint -- it only affects how Oracle performs the selects, has no real
side effects, and is fully Oracle-specific.

> Why don't you integrate your patch and then we will rerun our tests to
> make sure the function works as we had originally intended.

Are there any test cases that you guys could make available so that I
could experiment with whether or not the lock level checks are
necessary, or if they're duplicate code? Also, we should address Abe's
concern about whether the isolation level stuff is useful to databases
other than just DB2. My assumption has been that it is, but it'd be good
to confirm that this could be used more widely before making it a
published API.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: David Wisneski [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 05, 2007 11:35 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock 
> syntax WITH  USE AND KEEP UPDATE LOCKS
> 
> Patrick,
> 
> We were unaware that fetch plan properties could be set as Hints.  Now
> that we look at the code we see this,  but we did not find this when
> we read the OpenJPA documentation.  The only hint we found in the
> documentation was the OracleSelectHint and so our design was based on
> how OracleSelectHint was implemented.  OracleSelectHint is not
> implemented as a FetchPlan property.
> 
> Why don't you integrate your patch and then we will rerun our tests to
> make sure the function works as we had originally intended.
> 
> 
> On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> >[ 
> https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atl
assian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1248704
6 ]
> >
> > Patrick Linskey commented on OPENJPA-182:
> > -
> >
> > > > Hopefully, this will be useful for applications where 
> there are "hot" tables
> > > > that require pessimistic locking even though the rest 
> of the application
> > > > does better with optimistic.
> > >
> > > That's what our lock levels and lock APIs are for. I'm 
> still not clear on what this is
> > > adding to the mix for most DBs.
> >
> > Not really -- the lock levels allow the user to configure 
> how locking should happen, not what the isolation level 
> should be for the locks.
> >
> > I don't know about what levels of support non-DB2 databases 
> have for per-query isolation level configuration. Does anyone 
> have any experience with this in other databases?
> >
> > Oh, and regardless, we should change the base DBDictionary 
> to throw an exception if this FetchPlan setting is set but 
> not serviceable.
> >
> > One thing that we should test: I'm not convinced that the 
> lock level override in the DB2Dictionary code is necessary. 
> It's possible that the LockManager will already take into 
> account the current JDBCFetchConfiguration's lock level 
> settings when specifying the forUpdate setting for the 
> toSelect() clause. Some test cases will make it easy to 
> figure out the answer to this question.
> >
> > > db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> > > --
> > >
> > > Key: OPENJPA-182
> > > URL: 
> https://issues.apache.org/jira/browse/OPENJPA-182
> > > Project: OpenJPA
> > >  Issue Type: New Feature
> > >  Components: jdbc
> > > Environment: db2 database driver for zOS, AS400, 
> Unix, Windows, Linux
> > >Reporter: David Wisneski
> > > Assigned To: David Wisneski
> > > Attachments: OPENJPA-182.patch, openJPA182.patch
> > >
> > >
> > > A while back we changed the syntax of update locking from 
> FOR UPDATE OF  to  WITH RS USE AND KEEP UPDATE LOCKS.   
> Additional changes are required because
> 

[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows

[Abe White (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487078
 ] 

Abe White commented on OPENJPA-203:
---

If we don't want the subclasses to have to unset the lock value in case of 
exception, another option would be to have lock() delegate to lockInternal for 
setting the lock value, but to unset the lock value itself on error:

int oldValue = getLockValue(sm);
try {
lockInternal(...);
} catch (RuntimeException re) {
setLockValue(sm, oldValue);
throw re;
}

> Pessimistic Lock Manager not locking the rows 
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With  pessimistic lock manager multiple EMs are able to modify the same 
> object concurrently.

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

Re: Duplicate Query - where none exists

[Marc Prud'hommeaux]

Hmm. I don't see anything wrong with that mapping. How is the  
@OneToOne on the other side of the @ManyToOne defined (if you have one)?


It might be good to see the output of the mappingtool's validate  
action on your classes. E.g.:


  java org.apache.openjpa.jdbc.meta.MappingTool -action validate - 
Log DefaultLevel=TRACE META-INF/persistence.xml




On Apr 5, 2007, at 6:02 AM, Phill Moran wrote:

It is actually called categoryTypeFK and is char(45) related to ID,  
char(45) in

categoryType table.

I like the less is more but I remember getting some complaints in  
eclipse. I'll

try again

-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On  
Behalf Of Marc

Prud'hommeaux
Sent: April 5, 2007 2:42 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists


How is the "category.categoryTypeFK" column defined in the database?

An is there a corresponding "id" column in the table for the  
CategoryType class?


Also, when there is just a single column in the join for a  
ManyToOne, I think
you can skip setting the "referencedColumnName" attribute, since it  
will
implicitly join to the single primary key of the related table.  
I.e., you should

be able to do:

@ManyToOne
@JoinColumn(name = "categoryTypeFK")




On Apr 4, 2007, at 8:34 PM, Phill Moran wrote:


I think you may be on to something and have been looking into it.
It is mapped
and I thought worked but I am learning that I have a pretty messed up
config (I had both Toplink and OpenJPA, I am accessing fields  
directly

not through getters and am not positive that the mapping is right as
it is one to many). I have other versions of the same mapping and  
this

fairly commonly used class for my application as it represents
categories that are grouped by categoryTpye. It does have a relation
into the offended query class though

- Here is the pertinent parts of the Store class:

@ManyToOne
@JoinColumn(name = "typeFK", referencedColumnName = "id")
public Category getType() throws StoreTypeNotFoundException {
return type;
}

- Here is the pertinent parts of the Category class:

@Entity
@Table(name = "category", schema = "bidspec") @Inheritance(strategy =
InheritanceType.TABLE_PER_CLASS) @NamedQueries( {
@NamedQuery(name = "CategoryFXType", query = "SELECT c FROM

Category

c WHERE c.type = :type"),
@NamedQuery(name = "CategoryValueObjectFXPK", query = "SELECT c

FROM

Category c WHERE c.id = :primaryKey"),
@NamedQuery(name = "CategoryFXDescription", query = "SELECT c

FROM

Category c WHERE UPPER(c.description) LIKE :description ORDER BY
c.description") })
public class Category extends Persistable {

...

@ManyToOne
@JoinColumn(name = "categoryTypeFK", referencedColumnName = "id")
public CategoryType getType() {
return this.type;
}

Persistable is my base JPA persistable class housing the String id  
for

all persistable classes

-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf
Of Marc Prud'hommeaux
Sent: April 4, 2007 11:13 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

Phill-

While I'm not sure the cause of the duplicate query error, I do  
notice

the original cause in the nested stack trace is:


Caused by: <4|true|0.0.0>
org.apache.openjpa.persistence.ArgumentException: You cannot join on
column "category.categoryTypeFK".  It is not managed by a mapping
that supports joins.


It could be that this error is indirectly causing the next one.

Have you looked into this? How is categoryTypeFK mapped?




On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:


I did a workspace search and it exists in only one place. Also if I
comment out the one it complains about it complains about the next
one. But only in this java file. I even did an clean and build to
make sure there were no old class files hanging out.

-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: April 4, 2007 5:06 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

I think I saw this once.  The problem is in JPA named queries are  
all

contained in a single global namespace, so if you have to persistent
beans that define queries with the same name you get a warning.  It
would be nice if the warning told you where the duplicate
declarations are located.

-dain

On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:


Anyone seen this before

WARN   [main] openjpa.MetaData - Found duplicate query "StoreFXPK"
in "class
.".  Ignoring.

This class has only three such named queries all different names  
and

different actual queries. See following @NamedQueries( {
@NamedQuery(name = "StoreFXPK", query = "SELECT s FROM Store s

WHERE

s.id = :primaryKey"),
@NamedQuery(name = "StoreFXTypeAndName", quer

Re: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[David Wisneski]

Patrick,

We were unaware that fetch plan properties could be set as Hints.  Now
that we look at the code we see this,  but we did not find this when
we read the OpenJPA documentation.  The only hint we found in the
documentation was the OracleSelectHint and so our design was based on
how OracleSelectHint was implemented.  OracleSelectHint is not
implemented as a FetchPlan property.

Why don't you integrate your patch and then we will rerun our tests to
make sure the function works as we had originally intended.


On 4/5/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:


   [ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487046
 ]

Patrick Linskey commented on OPENJPA-182:
-

> > Hopefully, this will be useful for applications where there are "hot" tables
> > that require pessimistic locking even though the rest of the application
> > does better with optimistic.
>
> That's what our lock levels and lock APIs are for. I'm still not clear on 
what this is
> adding to the mix for most DBs.

Not really -- the lock levels allow the user to configure how locking should 
happen, not what the isolation level should be for the locks.

I don't know about what levels of support non-DB2 databases have for per-query 
isolation level configuration. Does anyone have any experience with this in 
other databases?

Oh, and regardless, we should change the base DBDictionary to throw an 
exception if this FetchPlan setting is set but not serviceable.

One thing that we should test: I'm not convinced that the lock level override 
in the DB2Dictionary code is necessary. It's possible that the LockManager will 
already take into account the current JDBCFetchConfiguration's lock level 
settings when specifying the forUpdate setting for the toSelect() clause. Some 
test cases will make it easy to figure out the answer to this question.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 only 
supports read or exclusive locks.
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
AbstractDB2Dictionary class and change the DB2Dictionary to append the correct 
LOCKS syntax depending on vendor, release and isolation level.

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

RE: Duplicate Query - where none exists

[Patrick Linskey]

FWIW, I think that I've seen an incorrect duplicate query warning at
some point as well.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
> Behalf Of Marc Prud'hommeaux
> Sent: Thursday, April 05, 2007 11:24 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Duplicate Query - where none exists
> 
> Hans-
> 
> I just did a query test with the 
> examples/hellojpa/Message.java class  
> in the latest openjpa-0.9.7-incubating-SNAPSHOT, and when I add:
> 
> @NamedQueries({
>  @NamedQuery(name="q1", query="select x from Message x"),
>  @NamedQuery(name="q1", query="select x from Message x")
> })
> 
> I get the duplicate query warning. But when I remove one of the  
> queries, I get no warning. So it appears to be working as expected.
> 
> Can you show us your class that is giving the warning, as 
> well as the  
> logging output with verbose logging enabled (i.e., setting  
> "openjpa.Log" to "DefaultLevel=TRACE")?
> 
> 
> On Apr 5, 2007, at 12:01 AM, Hans Prueller wrote:
> 
> > perhaps this can help out:
> >
> > I just started using OpenJPA and I have ONLY A SINGLE CLASS 
> WITHOUT  
> > ANY RELATIONS where I get this duplicate-query warning. So I can't  
> > believe that its related to that somehow...
> >
> > Hans
> >
> >  Original-Nachricht 
> > Datum: Wed, 4 Apr 2007 23:42:01 -0700
> > Von: Marc Prud\'hommeaux <[EMAIL PROTECTED]>
> > An: open-jpa-dev@incubator.apache.org
> > Betreff: Re: Duplicate Query - where none exists
> >
> >>
> >> How is the "category.categoryTypeFK" column defined in the 
> database?
> >>
> >> An is there a corresponding "id" column in the table for the
> >> CategoryType class?
> >>
> >> Also, when there is just a single column in the join for a 
> ManyToOne,
> >> I think you can skip setting the "referencedColumnName" attribute,
> >> since it will implicitly join to the single primary key of the
> >> related table. I.e., you should be able to do:
> >>
> >>@ManyToOne
> >>@JoinColumn(name = "categoryTypeFK")
> >>
> >>
> >>
> >>
> >> On Apr 4, 2007, at 8:34 PM, Phill Moran wrote:
> >>
> >>> I think you may be on to something and have been looking into it.
> >>> It is mapped
> >>> and I thought worked but I am learning that I have a pretty messed
> >>> up config (I
> >>> had both Toplink and OpenJPA, I am accessing fields directly not
> >>> through getters
> >>> and am not positive that the mapping is right as it is one to
> >>> many). I have
> >>> other versions of the same mapping and this fairly commonly used
> >>> class for my
> >>> application as it represents categories that are grouped by
> >>> categoryTpye. It
> >>> does have a relation into the offended query class though
> >>>
> >>> - Here is the pertinent parts of the Store class:
> >>>
> >>>   @ManyToOne
> >>>   @JoinColumn(name = "typeFK", referencedColumnName = "id")
> >>>   public Category getType() throws StoreTypeNotFoundException {
> >>>   return type;
> >>>   }
> >>>
> >>> - Here is the pertinent parts of the Category class:
> >>>
> >>> @Entity
> >>> @Table(name = "category", schema = "bidspec")
> >>> @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> >>> @NamedQueries( {
> >>>   @NamedQuery(name = "CategoryFXType", query = 
> "SELECT c FROM
> >>> Category c WHERE c.type = :type"),
> >>>   @NamedQuery(name = "CategoryValueObjectFXPK", 
> query = "SELECT c
> >>> FROM Category c WHERE c.id = :primaryKey"),
> >>>   @NamedQuery(name = "CategoryFXDescription", 
> query = "SELECT c
> >>> FROM Category c WHERE UPPER(c.description) LIKE :description  
> >>> ORDER BY
> >>> c.description") })
> >>> public class Category extends Persistable {
> >>>
> >>> ...
> >>>
> >>>   @ManyToOne
> >>>   @JoinColumn(name = "categoryTypeFK", 
> referencedColumnName = "id")
> >>>   public CategoryType getType() {
> >>>   return this.type;
> >>>   }
> >>>
> >>> Persistable is my base JPA persistable class housing the String id
> >>> for all
> >>> persistable classes
> >>>
> >>> -Original Message-
> >>> From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
> >>> Behalf Of Marc
> >>> Prud'hommeaux
> >>> Sent: April 4, 2007 11:13 PM
> >>> To: open-jpa-dev@incubator.apache.org
> >>> Subject: Re: Duplicate Query - where none exists
> >>>
> >>> Phill-
> >>>
> >>> While I'm not sure the cause of the duplicate query error, I do
> >>> notice the
> >

Re: Duplicate Query - where none exists

[Marc Prud'hommeaux]

Hans-

I just did a query test with the examples/hellojpa/Message.java class  
in the latest openjpa-0.9.7-incubating-SNAPSHOT, and when I add:


@NamedQueries({
@NamedQuery(name="q1", query="select x from Message x"),
@NamedQuery(name="q1", query="select x from Message x")
})

I get the duplicate query warning. But when I remove one of the  
queries, I get no warning. So it appears to be working as expected.


Can you show us your class that is giving the warning, as well as the  
logging output with verbose logging enabled (i.e., setting  
"openjpa.Log" to "DefaultLevel=TRACE")?



On Apr 5, 2007, at 12:01 AM, Hans Prueller wrote:


perhaps this can help out:

I just started using OpenJPA and I have ONLY A SINGLE CLASS WITHOUT  
ANY RELATIONS where I get this duplicate-query warning. So I can't  
believe that its related to that somehow...


Hans

 Original-Nachricht 
Datum: Wed, 4 Apr 2007 23:42:01 -0700
Von: Marc Prud\'hommeaux <[EMAIL PROTECTED]>
An: open-jpa-dev@incubator.apache.org
Betreff: Re: Duplicate Query - where none exists



How is the "category.categoryTypeFK" column defined in the database?

An is there a corresponding "id" column in the table for the
CategoryType class?

Also, when there is just a single column in the join for a ManyToOne,
I think you can skip setting the "referencedColumnName" attribute,
since it will implicitly join to the single primary key of the
related table. I.e., you should be able to do:

@ManyToOne
@JoinColumn(name = "categoryTypeFK")




On Apr 4, 2007, at 8:34 PM, Phill Moran wrote:


I think you may be on to something and have been looking into it.
It is mapped
and I thought worked but I am learning that I have a pretty messed
up config (I
had both Toplink and OpenJPA, I am accessing fields directly not
through getters
and am not positive that the mapping is right as it is one to
many). I have
other versions of the same mapping and this fairly commonly used
class for my
application as it represents categories that are grouped by
categoryTpye. It
does have a relation into the offended query class though

- Here is the pertinent parts of the Store class:

@ManyToOne
@JoinColumn(name = "typeFK", referencedColumnName = "id")
public Category getType() throws StoreTypeNotFoundException {
return type;
}

- Here is the pertinent parts of the Category class:

@Entity
@Table(name = "category", schema = "bidspec")
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@NamedQueries( {
@NamedQuery(name = "CategoryFXType", query = "SELECT c FROM
Category c WHERE c.type = :type"),
@NamedQuery(name = "CategoryValueObjectFXPK", query = "SELECT c
FROM Category c WHERE c.id = :primaryKey"),
@NamedQuery(name = "CategoryFXDescription", query = "SELECT c
FROM Category c WHERE UPPER(c.description) LIKE :description  
ORDER BY

c.description") })
public class Category extends Persistable {

...

@ManyToOne
@JoinColumn(name = "categoryTypeFK", referencedColumnName = "id")
public CategoryType getType() {
return this.type;
}

Persistable is my base JPA persistable class housing the String id
for all
persistable classes

-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc
Prud'hommeaux
Sent: April 4, 2007 11:13 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

Phill-

While I'm not sure the cause of the duplicate query error, I do
notice the
original cause in the nested stack trace is:


Caused by: <4|true|0.0.0>
org.apache.openjpa.persistence.ArgumentException: You cannot  
join on

column "category.categoryTypeFK".  It is not managed by a mapping
that
supports joins.


It could be that this error is indirectly causing the next one.

Have you looked into this? How is categoryTypeFK mapped?




On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:


I did a workspace search and it exists in only one place. Also if I
comment out the one it complains about it complains about the next
one. But only in this java file. I even did an clean and build to
make
sure there were no old class files hanging out.

-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: April 4, 2007 5:06 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

I think I saw this once.  The problem is in JPA named queries  
are all
contained in a single global namespace, so if you have to  
persistent

beans that define queries with the same name you get a warning.  It
would be nice if the warning told you where the duplicate
declarations
are located.

-dain

On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:


Anyone seen this before

WARN   [main] openjpa.MetaData - Found duplicate query "StoreFXPK"
in "class
.".  Ignoring.

This class has only three such named queries all different  
names and

di

[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows

[Srinivasa (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487070
 ] 

Srinivasa commented on OPENJPA-203:
---

My initial approach was the same that we could move the responsibility of 
setting the lock-level to lockInternal. The only concern that lead me to this 
approach was that - if an overriding lockInternal method calls super() 
following up with some code that can throw an exception - the lockInternal 
override will have to unset the lock in its catch block to unset the value set 
by the super call. (Note the current override PessimisticLockManager does not 
run into this issue as the super() call is at the end).

So I went with the idea that the lock() is responsible for setting the lock 
level, and in the special case of VersionLockManager where its lockInternal 
code needs the lock-level set before to avoid infinite recursion - it can 
handle the case by setting, later unsetting - keeping the lock-level change 
need local.

That being said I dont terribly mind changing to the suggested approach.

> Pessimistic Lock Manager not locking the rows 
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With  pessimistic lock manager multiple EMs are able to modify the same 
> object concurrently.

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

RE: API or Query hints

[Patrick Linskey]

> Do we need this function in 0.9.7 or can it wait until 0.9.8?

I don't have a strong opinion either way. If we decide to hold it for
0.9.8, then I think that it's important for us to either remove the
current functionality, or make sure it's understood that the current API
is subject to change without backwards-compatibility.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Michael Dick [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, April 04, 2007 6:50 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: API or Query hints
> 
> Do we need this function in 0.9.7 or can it wait until 0.9.8?
> 
> When we're dealing with external APIs we need to be very 
> careful that we're
> doing the right thing. I think we need some time to come to a 
> consensus on
> the correct approach and I'd rather not delay 0.9.7 in the 
> meantime. Abe
> cleaned up the code I dropped for default schemas earlier today, so I
> believe this is the last outstanding issue with 0.9.7.
> 
> FTR I'm not voting for or against either implementation - I 
> just don't want
> to commit to one path until we can agree to one of them.
> 
> If the consensus is that this function should be included in 
> 0.9.7 then I'll
> withdraw my comment and wait.
> 
> Other gratuitous opinions:
> 
> +1 to using a JIRA or the mailing list to discuss external 
> changes before
> committing.
> 
> +1 to Abe's comment regarding hint naming conventions, we 
> should try to stay
> consistent.
> 
> 
> On 4/4/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > In the interests of putting my money where my mouth is, I attached a
> > patch to the JIRA issue, and included a description of the 
> patch in the
> > JIRA issue. Hopefully, this will help a) make the problem 
> and different
> > solutions more concrete, and b) quell any concerns about
> > implementability of the approach that I outlined.
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > 
> __
> _
> > Notice:  This email message, together with any attachments, 
> may contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and 
>  affiliated
> > entities,  that may be confidential,  proprietary,  
> copyrighted  and/or
> > legally privileged, and is intended solely for the use of 
> the individual
> > or entity named in this message. If you are not the 
> intended recipient,
> > and have received this message in error, please immediately 
> return this
> > by email and then delete it.
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, April 04, 2007 3:22 PM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: API or Query hints
> > >
> > > I think any time we make a change to the external view of the
> > > project
> > > we need to have a discussion first.
> > >
> > > IMHO The JIRA process is pretty good for this kind of 
> stuff. Someone
> > > proposes a feature with non-standardized external behavior
> > > and writes
> > > up what it should look like. Then we agree on the details and
> > > go for it.
> > >
> > > On this particular issue, I can see valid reasons for 
> having an API
> > > that modifies the behavior of the query, but also 
> understand why it
> > > might be good to mirror that behavior using query hints. But
> > > whichever way we go, we need to agree on the name and semantics of
> > > the API/property and how to pass it to the internal structures for
> > > execution.
> > >
> > > There is a danger in thinking of these as "hints". As I would
> > > like to
> > > see it, the only down side to not recognizing a query 
> hint is lower
> > > performance. But if your application doesn't behave 
> correctly if the
> > > implementation can't do anything useful with the hint, 
> then it's not
> > > a hint but an application requirement. And if the hint can only be
> > > executed in some specific databases, then we need to decide if we
> > > throw an exception if the database isn't capable.
> > >
> > > Craig
> > >
> > > On Apr 4, 2007, at 2:17 PM, Abe White wrote:
> > >
> > > >> ... for certain values of "our". I think that it's
> > > important that we
> > > >> discuss API decisions as a group, as they have significant
> > > impacts on
> > > >> the OpenJPA product moving forward. This is especially
> > > important when
> > > >> there are dissenting v

Re: [jira] Updated: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Ritika Maheshwari]

Finally, I replicated the logic in DB2Dictionary, but I noticed that

sometimes the logic checked >for "serializable" and sometimes it checked for
"read-uncommitted". I preserved these checks, >but was this intentional? I'm
not all that clear about what the optimizations are, so just wanted >to
ensure that that wasn't a typo.

No it is not a typo.It was intended.



On 4/4/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:



[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Patrick Linskey updated OPENJPA-182:


   Attachment: OPENJPA-182.patch

For the sake of discussion, I've attached an alternate patch that uses a
new JDBCFetchPlan.setIsolationLevel() instead of a hint for isolation
level, and uses JDBCFetchConfiguration.getReadLockLevel() to determine
whether or not to do a SELECT ... FOR UPDATE.

If the read lock level is set to LockLevels.LEVEL_WRITE, then the FOR
UPDATE is included; if the read lock level is set to LockLevels.LEVEL_READ,
then no FOR UPDATE is used. If the read lock level is
LockLevels.LEVEL_NONE, then the default behavior is used. (This is
possibly not the best use of LEVEL_NONE -- I'm not sure if LEVEL_NONE means
'default' or something else. But for the purposes of demonstration, it
seemed expedient to use it. Adding a new LEVEL_DEFAULT constant might make
more sense.)

Also, I directly reused the java.sql.Connection constants, which is
possibly non-ideal; we might want to discuss making our own constants. Or
not.

So, in this model, if there were a test case for this stuff, I would have
changed the test case to do:

Query q = em.createQuery(...);
JDBCFetchPlan plan = (JDBCFetchPlan) ((OpenJPAQuery)
query).getFetchPlan();
plan.setIsolationLevel(Connection.TRANSACTION_SERIALIZABLE);
plan.setReadLockMode(LockModeType.WRITE); // force a FOR UPDATE
List l = q.getResultList();

Note also that this model allows the isolation level and read lock mode to
be configured on the EM itself, for use in find() calls and relationship
lookups, and as the default settings for the fetch plans of queries created
from the EM.

Finally, I replicated the logic in DB2Dictionary, but I noticed that
sometimes the logic checked for "serializable" and sometimes it checked for
"read-uncommitted". I preserved these checks, but was this intentional? I'm
not all that clear about what the optimizations are, so just wanted to
ensure that that wasn't a typo.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows,
Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE
OF  to  WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required
because
> 1.  if isolation=serializable is configured, then the syntax should
be  WITH RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE
AND KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because
DB2/400 only supports read or exclusive locks.
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the
AbstractDB2Dictionary class and change the DB2Dictionary to append the
correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Patrick Linskey (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487046
 ] 

Patrick Linskey commented on OPENJPA-182:
-

> > Hopefully, this will be useful for applications where there are "hot" 
> > tables 
> > that require pessimistic locking even though the rest of the application 
> > does better with optimistic.
> 
> That's what our lock levels and lock APIs are for. I'm still not clear on 
> what this is 
> adding to the mix for most DBs.

Not really -- the lock levels allow the user to configure how locking should 
happen, not what the isolation level should be for the locks.

I don't know about what levels of support non-DB2 databases have for per-query 
isolation level configuration. Does anyone have any experience with this in 
other databases?

Oh, and regardless, we should change the base DBDictionary to throw an 
exception if this FetchPlan setting is set but not serviceable.

One thing that we should test: I'm not convinced that the lock level override 
in the DB2Dictionary code is necessary. It's possible that the LockManager will 
already take into account the current JDBCFetchConfiguration's lock level 
settings when specifying the forUpdate setting for the toSelect() clause. Some 
test cases will make it easy to figure out the answer to this question.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

Re: [jira] Commented: (OPENJPA-168) sql optimize n rows query hint

[Ritika Maheshwari]

It has not been documented in the OPENJPA documentation.




On 4/4/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:



   [
https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486820]

Patrick Linskey commented on OPENJPA-168:
-

Has this new feature been documented?

> sql optimize n rows query hint
> --
>
> Key: OPENJPA-168
> URL: https://issues.apache.org/jira/browse/OPENJPA-168
> Project: OpenJPA
>  Issue Type: New Feature
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-168.patch.txt, OPENJPA-168.patch2.txt
>
>
> There werre various comments from Patrick, Abe and Kevin Sutter about
the code that I checked related to Optimize hint.  So I have gone back and
relooked at this and wil be making some changes.  At Kevin's suggestion I
will do this through a JIRA feature so that folks will have opportunity to
comment on this before the code is actually done and checked in.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Abe White (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487000
 ] 

Abe White commented on OPENJPA-182:
---

> Hopefully, this will be useful for applications where there are "hot" tables 
> that require pessimistic locking even though the rest of the application does 
> better with optimistic.

That's what our lock levels and lock APIs are for.  I'm still not clear on what 
this is adding to the mix for most DBs.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows

[Abe White (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486999
 ] 

Abe White commented on OPENJPA-203:
---

Looks good.  Although I think I'd prefer to make lockInternal() responsible for 
setting the lock level rather than having to set it and unset it so that lock() 
can set it again... it's just too ugly.  So instead we just remove the setting 
of the lock level in lock() and make VersionLockManager only unset the lock 
level in its lockInternal if an exception occurs.  PessimisticLockManager 
wouldn't have to change (outside of the changes already in your patch) because 
it delegates to super.lockInternal already, so the lock level would get set 
appropriately.  

> Pessimistic Lock Manager not locking the rows 
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With  pessimistic lock manager multiple EMs are able to modify the same 
> object concurrently.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Craig Russell (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486997
 ] 

Craig Russell commented on OPENJPA-182:
---

Hopefully, this will be useful for applications where there are "hot" tables 
that require pessimistic locking even though the rest of the application does 
better with optimistic. Take the example of an Order/OrderLine where there are 
lots of updates of the Order and/or associated OrderLine. If several threads 
get the same Order, they will ultimately conflict and waste time. If the query 
to retrieve the Order is marked as pessimistic (WRITE) then these threads will 
serialize and all of their work will complete.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS

[Abe White (JIRA)]

[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486987
 ] 

Abe White commented on OPENJPA-182:
---

What is setting the isolation level this way actually doing?  For anything 
other than DB2 right now, it looks like it doesn't do anything.  And even for 
DB2, it's unclear to me exactly what the isolation level hint is doing, and why 
the information can't be gleaned from the global setting or the connection.  It 
seems very misleading to me to have a setIsolationLevel API (or generic 
"IsolationLevel" hint) that doesn't actually change the connection's isolation 
level.

If we can determine that this API is actually useful for more than DB2, and if 
we can name it appropriately for what it actually does, then I like Patrick's 
proposal of a FetchPlan API.  The fact that all FetchPlan properties can be 
expressed as hints should make everyone happy.  But if this is just a DB2 
thing, then we should rename the hint to have a DB2-specific name and be done 
with it IMO.

> db2 update lock syntax  WITH  USE AND KEEP UPDATE LOCKS
> --
>
> Key: OPENJPA-182
> URL: https://issues.apache.org/jira/browse/OPENJPA-182
> Project: OpenJPA
>  Issue Type: New Feature
>  Components: jdbc
> Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-182.patch, openJPA182.patch
>
>
> A while back we changed the syntax of update locking from FOR UPDATE OF  to  
> WITH RS USE AND KEEP UPDATE LOCKS.   Additional changes are required because 
> 1.  if isolation=serializable is configured, then the syntax should be  WITH 
> RR USE AND KEEP UDPATE LOCKS
> 2.  when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND 
> KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 
> only supports read or exclusive locks. 
> 3.  DB2 supports both a FETCH FIRST  ROWS and update LOCKS clauses.
> So we change supportsLockingWithSelectRange = true in the 
> AbstractDB2Dictionary class and change the DB2Dictionary to append the 
> correct LOCKS syntax depending on vendor, release and isolation level.

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

Re: why not an EntityExistsException was thrown?

[Craig L Russell]

Hi Wanyna,

Whenever you query for entities, the result entities are put into  
your persistence context. So when you then try to persist another  
entity with the same identity the provider finds the query result in  
the persistence context and throws EntityExistsException.


Craig

On Apr 4, 2007, at 9:47 PM, wanyna wrote:



Your explaination is clearly if I only show my test case 1.
My test case 2, add a query before persist, then get  
EntityExistsException.
The result of  query hold some object no association with the  
object to

persist.
Why this time the object exists in persistence context?



Craig L Russell wrote:


If you look at the exception that is thrown from the database, it's a
pretty general exception.

"The statement was aborted because it would have caused a duplicate
key  value in a unique or primary key constraint or unique index
identified by  'SQL070403054930170' defined on 'BSC'."

This might have been caused by a unique constraint, which would not
be properly reported as EntityExistsException.

Sadly, there is no standard SQL exception that specifically tells the
provider (OpenJPA) that there was a primary key constraint violation.
And you might also note that every database has its own way to report
exceptions like this.

What the EntityExistsException does is to report that there is
already an entity with the same primary key in the persistence
context. It doesn't report that there was a problem writing the
entity to the database.

If you're looking for better error reporting you can flush as part of
the application-level persist operation. That way your application
can catch a persistence exception that is caused either by persist or
flush and report it as a "problem persisting entity" to your caller.

But there is a down side to this. If you flush immediately after
persist, the provider cannot optimize for performance. So it's a
tradeoff that you need to make in your application.

If you're keen on "fixing" this situation, I'd encourage you to
volunteer to look at the databases and how they report unique and
primary key constraint violations and see if it's possible to parse
the sql code and report string to positively identify a primary key
constraint violation.

Craig

On Apr 3, 2007, at 9:42 PM, wanyna wrote:



I can't find EntityExistsException nested in RollbackExceptions.
http://www.nabble.com/file/7646/exception.jpg

Will exception mechanism be planned to improve?
I think it's very important.


Patrick Linskey wrote:


Cool -- that explains it then.

EM.commit() must throw RollbackExceptions (and
org.apache.openjpa.persistence.RollbackException extends
javax.persistence.RollbackException) when the transaction is
rolled back
during the course of the commit.

If you get the nested exception from the RollbackException, I bet
that
it's instanceof EntityExistsException.

Clearly, however, something is wonky with our exception printing
algorithm.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

___ 
__

__
Notice:  This email message, together with any attachments, may
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
entities,  that may be confidential,  proprietary,  copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.


-Original Message-
From: wanyna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 8:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: why not an EntityExistsException was thrown?


actual class of the exception:
class org.apache.openjpa.persistence.RollbackException
<2|true|0.9.7-incubating-SNAPSHOT>
org.apache.openjpa.persistence.RollbackException: The
transaction has been
rolled back.  See the nested exceptions for details on the errors
that
occurred.
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:417)
at test.Main.main(Main.java:82)
Caused by: <0|true|0.9.7-incubating-SNAPSHOT>
org.apache.openjpa.persistence.PersistenceException: The
transaction has
been rolled back.  See the nested exceptions for details on
the errors that
occurred.
at
org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerI
mpl.java:2091)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java: 
1836)

at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerIm
pl.java:1754)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalMana
gedRuntime.java:76)
at
org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBr
oker.java:863)
at
org.apache.openjpa.persistence.EntityManagerImpl.c

RE: Duplicate Query - where none exists

[Phill Moran]

It is actually called categoryTypeFK and is char(45) related to ID, char(45) in
categoryType table.

I like the less is more but I remember getting some complaints in eclipse. I'll
try again

-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc
Prud'hommeaux
Sent: April 5, 2007 2:42 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists


How is the "category.categoryTypeFK" column defined in the database?

An is there a corresponding "id" column in the table for the CategoryType class?

Also, when there is just a single column in the join for a ManyToOne, I think
you can skip setting the "referencedColumnName" attribute, since it will
implicitly join to the single primary key of the related table. I.e., you should
be able to do:

@ManyToOne
@JoinColumn(name = "categoryTypeFK")




On Apr 4, 2007, at 8:34 PM, Phill Moran wrote:

> I think you may be on to something and have been looking into it.  
> It is mapped
> and I thought worked but I am learning that I have a pretty messed up 
> config (I had both Toplink and OpenJPA, I am accessing fields directly 
> not through getters and am not positive that the mapping is right as 
> it is one to many). I have other versions of the same mapping and this 
> fairly commonly used class for my application as it represents 
> categories that are grouped by categoryTpye. It does have a relation 
> into the offended query class though
>
> - Here is the pertinent parts of the Store class:
>
>   @ManyToOne
>   @JoinColumn(name = "typeFK", referencedColumnName = "id")
>   public Category getType() throws StoreTypeNotFoundException {
>   return type;
>   }
>
> - Here is the pertinent parts of the Category class:
>
> @Entity
> @Table(name = "category", schema = "bidspec") @Inheritance(strategy = 
> InheritanceType.TABLE_PER_CLASS) @NamedQueries( {
>   @NamedQuery(name = "CategoryFXType", query = "SELECT c FROM
Category 
> c WHERE c.type = :type"),
>   @NamedQuery(name = "CategoryValueObjectFXPK", query = "SELECT c
FROM 
> Category c WHERE c.id = :primaryKey"),
>   @NamedQuery(name = "CategoryFXDescription", query = "SELECT c
FROM 
> Category c WHERE UPPER(c.description) LIKE :description ORDER BY
> c.description") })
> public class Category extends Persistable {
>
> ...
>
>   @ManyToOne
>   @JoinColumn(name = "categoryTypeFK", referencedColumnName = "id")
>   public CategoryType getType() {
>   return this.type;
>   }
>
> Persistable is my base JPA persistable class housing the String id for 
> all persistable classes
>
> -Original Message-
> From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf 
> Of Marc Prud'hommeaux
> Sent: April 4, 2007 11:13 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Duplicate Query - where none exists
>
> Phill-
>
> While I'm not sure the cause of the duplicate query error, I do notice 
> the original cause in the nested stack trace is:
>
>> Caused by: <4|true|0.0.0>
>> org.apache.openjpa.persistence.ArgumentException: You cannot join on 
>> column "category.categoryTypeFK".  It is not managed by a mapping 
>> that supports joins.
>
> It could be that this error is indirectly causing the next one.
>
> Have you looked into this? How is categoryTypeFK mapped?
>
>
>
>
> On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:
>
>> I did a workspace search and it exists in only one place. Also if I 
>> comment out the one it complains about it complains about the next 
>> one. But only in this java file. I even did an clean and build to 
>> make sure there were no old class files hanging out.
>>
>> -Original Message-
>> From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
>> Sent: April 4, 2007 5:06 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Re: Duplicate Query - where none exists
>>
>> I think I saw this once.  The problem is in JPA named queries are all 
>> contained in a single global namespace, so if you have to persistent 
>> beans that define queries with the same name you get a warning.  It 
>> would be nice if the warning told you where the duplicate 
>> declarations are located.
>>
>> -dain
>>
>> On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:
>>
>>> Anyone seen this before
>>>
>>> WARN   [main] openjpa.MetaData - Found duplicate query "StoreFXPK"
>>> in "class
>>> .".  Ignoring.
>>>
>>> This class has only three such named queries all different names and 
>>> different actual queries. See following @NamedQueries( {
>>> @NamedQuery(name = "StoreFXPK", query = "SELECT s FROM Store s
>> WHERE
>>> s.id = :primaryKey"),
>>> @NamedQuery(name = "StoreFXTypeAndName", query = "SELECT s FROM 
>>> Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
>>> UPPER(s.displayName) = :storeName2"),
>>> @NamedQuery(name = "StoreFXName", query = "SELECT s FROM Store s
>>
>>> WHERE UPPER(s.name) 

[jira] Updated: (OPENJPA-203) Pessimistic Lock Manager not locking the rows

[Srinivasa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Srinivasa updated OPENJPA-203:
--

Attachment: NotesAndDiff.txt

> Pessimistic Lock Manager not locking the rows 
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With  pessimistic lock manager multiple EMs are able to modify the same 
> object concurrently.

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

[jira] Created: (OPENJPA-203) Pessimistic Lock Manager not locking the rows

[Srinivasa (JIRA)]

Pessimistic Lock Manager not locking the rows 
--

 Key: OPENJPA-203
 URL: https://issues.apache.org/jira/browse/OPENJPA-203
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.6, 0.9.0
 Environment: ran against Oracle
Reporter: Srinivasa


With  pessimistic lock manager multiple EMs are able to modify the same object 
concurrently.

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

[jira] Updated: (OPENJPA-203) Pessimistic Lock Manager not locking the rows

[Srinivasa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Srinivasa updated OPENJPA-203:
--

Attachment: testcase.zip

> Pessimistic Lock Manager not locking the rows 
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: testcase.zip
>
>
> With  pessimistic lock manager multiple EMs are able to modify the same 
> object concurrently.

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

Re: Duplicate Query - where none exists

[Marc Prud'hommeaux]

How is the "category.categoryTypeFK" column defined in the database?

An is there a corresponding "id" column in the table for the  
CategoryType class?


Also, when there is just a single column in the join for a ManyToOne,  
I think you can skip setting the "referencedColumnName" attribute,  
since it will implicitly join to the single primary key of the  
related table. I.e., you should be able to do:


@ManyToOne
@JoinColumn(name = "categoryTypeFK")




On Apr 4, 2007, at 8:34 PM, Phill Moran wrote:

I think you may be on to something and have been looking into it.  
It is mapped
and I thought worked but I am learning that I have a pretty messed  
up config (I
had both Toplink and OpenJPA, I am accessing fields directly not  
through getters
and am not positive that the mapping is right as it is one to  
many). I have
other versions of the same mapping and this fairly commonly used  
class for my
application as it represents categories that are grouped by  
categoryTpye. It

does have a relation into the offended query class though

- Here is the pertinent parts of the Store class:

@ManyToOne
@JoinColumn(name = "typeFK", referencedColumnName = "id")
public Category getType() throws StoreTypeNotFoundException {
return type;
}

- Here is the pertinent parts of the Category class:

@Entity
@Table(name = "category", schema = "bidspec")
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@NamedQueries( {
@NamedQuery(name = "CategoryFXType", query = "SELECT c FROM
Category c WHERE c.type = :type"),
@NamedQuery(name = "CategoryValueObjectFXPK", query = "SELECT c
FROM Category c WHERE c.id = :primaryKey"),
@NamedQuery(name = "CategoryFXDescription", query = "SELECT c
FROM Category c WHERE UPPER(c.description) LIKE :description ORDER BY
c.description") })
public class Category extends Persistable {

...

@ManyToOne
@JoinColumn(name = "categoryTypeFK", referencedColumnName = "id")
public CategoryType getType() {
return this.type;
}

Persistable is my base JPA persistable class housing the String id  
for all

persistable classes

-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On  
Behalf Of Marc

Prud'hommeaux
Sent: April 4, 2007 11:13 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

Phill-

While I'm not sure the cause of the duplicate query error, I do  
notice the

original cause in the nested stack trace is:


Caused by: <4|true|0.0.0>
org.apache.openjpa.persistence.ArgumentException: You cannot join on
column "category.categoryTypeFK".  It is not managed by a mapping  
that

supports joins.


It could be that this error is indirectly causing the next one.

Have you looked into this? How is categoryTypeFK mapped?




On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:


I did a workspace search and it exists in only one place. Also if I
comment out the one it complains about it complains about the next
one. But only in this java file. I even did an clean and build to  
make

sure there were no old class files hanging out.

-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: April 4, 2007 5:06 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Duplicate Query - where none exists

I think I saw this once.  The problem is in JPA named queries are all
contained in a single global namespace, so if you have to persistent
beans that define queries with the same name you get a warning.  It
would be nice if the warning told you where the duplicate  
declarations

are located.

-dain

On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:


Anyone seen this before

WARN   [main] openjpa.MetaData - Found duplicate query "StoreFXPK"
in "class
.".  Ignoring.

This class has only three such named queries all different names and
different actual queries. See following @NamedQueries( {
@NamedQuery(name = "StoreFXPK", query = "SELECT s FROM Store s

WHERE

s.id = :primaryKey"),
@NamedQuery(name = "StoreFXTypeAndName", query = "SELECT s FROM
Store s WHERE s.type = :type AND UPPER(s.name) LIKE :storeName OR
UPPER(s.displayName) = :storeName2"),
@NamedQuery(name = "StoreFXName", query = "SELECT s FROM Store s



WHERE UPPER(s.name) = :storeName OR UPPER(s.displayName) =
:storeName2")
})

I even renamed the duplicate parms to make sure it was not a trickle
down exception. Not only that, if I comment out the StoreFXPK  
query I

get the same error on the next named Query. I did a search on the
workspace an this is only used in one place (factory class) and
define in another (persistent class). I have no doubt this is
something I have done but am unsure what it is I get the follow  
stack

trace when executing the following line:

Query q = em.createNamedQuery("StoreFXName"); <- not the same query
mentioned i

Re: Duplicate Query - where none exists

[Hans Prueller]

perhaps this can help out: 

I just started using OpenJPA and I have ONLY A SINGLE CLASS WITHOUT ANY 
RELATIONS where I get this duplicate-query warning. So I can't believe that its 
related to that somehow...

Hans

 Original-Nachricht 
Datum: Wed, 4 Apr 2007 23:42:01 -0700
Von: Marc Prud\'hommeaux <[EMAIL PROTECTED]>
An: open-jpa-dev@incubator.apache.org
Betreff: Re: Duplicate Query - where none exists

> 
> How is the "category.categoryTypeFK" column defined in the database?
> 
> An is there a corresponding "id" column in the table for the  
> CategoryType class?
> 
> Also, when there is just a single column in the join for a ManyToOne,  
> I think you can skip setting the "referencedColumnName" attribute,  
> since it will implicitly join to the single primary key of the  
> related table. I.e., you should be able to do:
> 
>   @ManyToOne
>   @JoinColumn(name = "categoryTypeFK")
> 
> 
> 
> 
> On Apr 4, 2007, at 8:34 PM, Phill Moran wrote:
> 
> > I think you may be on to something and have been looking into it.  
> > It is mapped
> > and I thought worked but I am learning that I have a pretty messed  
> > up config (I
> > had both Toplink and OpenJPA, I am accessing fields directly not  
> > through getters
> > and am not positive that the mapping is right as it is one to  
> > many). I have
> > other versions of the same mapping and this fairly commonly used  
> > class for my
> > application as it represents categories that are grouped by  
> > categoryTpye. It
> > does have a relation into the offended query class though
> >
> > - Here is the pertinent parts of the Store class:
> >
> > @ManyToOne
> > @JoinColumn(name = "typeFK", referencedColumnName = "id")
> > public Category getType() throws StoreTypeNotFoundException {
> > return type;
> > }
> >
> > - Here is the pertinent parts of the Category class:
> >
> > @Entity
> > @Table(name = "category", schema = "bidspec")
> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> > @NamedQueries( {
> > @NamedQuery(name = "CategoryFXType", query = "SELECT c FROM
> > Category c WHERE c.type = :type"),
> > @NamedQuery(name = "CategoryValueObjectFXPK", query = "SELECT c
> > FROM Category c WHERE c.id = :primaryKey"),
> > @NamedQuery(name = "CategoryFXDescription", query = "SELECT c
> > FROM Category c WHERE UPPER(c.description) LIKE :description ORDER BY
> > c.description") })
> > public class Category extends Persistable {
> >
> > ...
> >
> > @ManyToOne
> > @JoinColumn(name = "categoryTypeFK", referencedColumnName = "id")
> > public CategoryType getType() {
> > return this.type;
> > }
> >
> > Persistable is my base JPA persistable class housing the String id  
> > for all
> > persistable classes
> >
> > -Original Message-
> > From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On  
> > Behalf Of Marc
> > Prud'hommeaux
> > Sent: April 4, 2007 11:13 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: Duplicate Query - where none exists
> >
> > Phill-
> >
> > While I'm not sure the cause of the duplicate query error, I do  
> > notice the
> > original cause in the nested stack trace is:
> >
> >> Caused by: <4|true|0.0.0>
> >> org.apache.openjpa.persistence.ArgumentException: You cannot join on
> >> column "category.categoryTypeFK".  It is not managed by a mapping  
> >> that
> >> supports joins.
> >
> > It could be that this error is indirectly causing the next one.
> >
> > Have you looked into this? How is categoryTypeFK mapped?
> >
> >
> >
> >
> > On Apr 4, 2007, at 8:03 PM, Phill Moran wrote:
> >
> >> I did a workspace search and it exists in only one place. Also if I
> >> comment out the one it complains about it complains about the next
> >> one. But only in this java file. I even did an clean and build to  
> >> make
> >> sure there were no old class files hanging out.
> >>
> >> -Original Message-
> >> From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
> >> Sent: April 4, 2007 5:06 PM
> >> To: open-jpa-dev@incubator.apache.org
> >> Subject: Re: Duplicate Query - where none exists
> >>
> >> I think I saw this once.  The problem is in JPA named queries are all
> >> contained in a single global namespace, so if you have to persistent
> >> beans that define queries with the same name you get a warning.  It
> >> would be nice if the warning told you where the duplicate  
> >> declarations
> >> are located.
> >>
> >> -dain
> >>
> >> On Apr 3, 2007, at 10:07 PM, Phill Moran wrote:
> >>
> >>> Anyone seen this before
> >>>
> >>> WARN   [main] openjpa.MetaData - Found duplicate query "StoreFXPK"
> >>> in "class
> >>> .".  Ignoring.
> >>>
> >>> This class has only three such named queries all different names and
> >>> different actual queries. See following @NamedQueries( {
> >>>   @NamedQuery(name = "StoreFXPK", query = "SELECT s FROM Store s
> >> WHERE
> >>> s.id = :primaryKey"),
> >>>   @NamedQuery(name