Re: Duplicate Query - where none exists
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 = 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
[jira] Created: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
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.
RE: Duplicate Query - where none exists
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) = :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
Re: why not an EntityExistsException was thrown?
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
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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
[ 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.
Re: [jira] Commented: (OPENJPA-168) sql optimize n rows query hint
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 isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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
[ 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: 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
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(
Re: Duplicate Query - where none exists
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, query = SELECT s FROM
Store s WHERE s.type =
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[
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: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
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 isolation 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 isolation 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
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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 isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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 isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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
[
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:
specOnly Basic, Column, Lob, Temporal, and Enumerated mapping annotations may
portably be used to map the persistent fields or properties of classes
annotated as Embeddable./spec
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 xsd:complexType
name=embeddable-attributes the xsd:element name=embedded
type=orm:embeddedminOccurs=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:
?xml version=1.0 encoding=UTF-8?
entity-mappings xmlns=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
entity class=A
table name=TableA/
attributes
id name=id
column name=ID/
/id
embedded name=objB/
/attributes
/entity
embeddable class=B
attributes
basic name=str1
column name=COL2/
/basic
basic name=d
column name=DateCol/
/basic
embedded name=objC/
/embeddable
embeddable class=C
attributes
basic name=str2
column name=COL3/
/basic
/embeddable
/entity-mappings
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.
RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
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 isolation USE AND KEEP UPDATE LOCKS
Informix has the following
SET TRANSACTION
http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/co
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]
http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/co
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]Syntaxhttp://msdn2.microsoft.com/en-us/library/ms173763.aspx#
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 isolation 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
annotations / tags in JIRA?
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.
[jira] Created: (OPENJPA-205) JPA2 Follow-Up
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: Using query hints for mapping extensions in orm.xml
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 provider and orm.xmlentity-mappings xsi:schemaLocation=..openjpa_orm_1_0.xsd stanza to enforce the orm must be applied using openjpa provider. persistence.xml persistence ... persistence-unit name=MyEmployeePU provider org.apache.openjpa.persistence.PersistenceProviderImpl/provider mapping-fileMETA-INF/openjpa_orm.xml/mapping-file .. openjpa_orm.xml entity-mappings . xsi:schemaLocation= 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
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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 isolation USE AND KEEP UPDATE LOCKS
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]Syntaxhttp://msdn2.microsoft.com/en-us/library/ms187373.aspx#
table_hint ::=
[ 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 isolation USE AND KEEP UPDATE LOCKS
Informix has the following
SET TRANSACTION
http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/co
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]
http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/co
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]Syntaxhttp://msdn2.microsoft.com/en-us/library/ms173763.aspx#
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
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ 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 isolation 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: 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 [
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 - t 1094861122, conn 1652187770 [0 ms] spent 1171 bugwineTour TRACE [main] openjpa.jdbc.SQL - t 1094861122, 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 - t 1094861122, 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.init( 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: why not an EntityExistsException was thrown?
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.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
