JOIN in subselect problems
Is there anything wrong with the following query?
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM MailingList l JOIN l.subscribers m)
OpenJPA (0.9.6) parses this correctly, but can't seems to be missing the
JOIN clause or some table names from the generated SQL:
org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: syntax error at
or near WHERE {prepstmnt 27475707 UPDATE FB_EMAILS SET totalDeliveries =
(totalDeliveries + ?) WHERE email IN (SELECT DISTINCT t2.email FROM WHERE
(t2.email IN (SELECT t3.email FROM FB_EMAILS t3 WHERE t0.id = t1.id AND
t1.subscribers_email = t3.email))) [params=(long) 1]} [code=0, state=42601]
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:188)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$800(LoggingConnectionDecorator.java:53)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:854)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:266)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:266)
org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1360)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(JDBCStoreQuery.java:491)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate(JDBCStoreQuery.java:420)
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:685)
org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeUpdate(QueryCacheStoreQuery.java:343)
org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1028)
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:793)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:868)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:864)
org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:560)
org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:304)
Thanks,
Roger
--
View this message in context:
http://www.nabble.com/JOIN-in-subselect-problems-tf3394694.html#a9450588
Sent from the open-jpa-dev mailing list archive at Nabble.com.
[jira] Assigned: (OPENJPA-149) non-jta-data-source must be specified in WebSphere environments
[ https://issues.apache.org/jira/browse/OPENJPA-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter reassigned OPENJPA-149: Assignee: Kevin Sutter non-jta-data-source must be specified in WebSphere environments --- Key: OPENJPA-149 URL: https://issues.apache.org/jira/browse/OPENJPA-149 Project: OpenJPA Issue Type: Improvement Components: kernel Environment: WebSphere Reporter: Patrick Linskey Assigned To: Kevin Sutter The suspend(), resume(), begin(), and commit() methods in org.apache.openjpa.ee.WASManagedRuntime$WASTransaction all throw exceptions. This prevents the logic in org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq from executing. See OPENJPA-144 for relevant stack traces. In particular, look at the Only-JTASpecified.txt trace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-149) non-jta-data-source must be specified in WebSphere environments
[ https://issues.apache.org/jira/browse/OPENJPA-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter updated OPENJPA-149: - Fix Version/s: 0.9.7 Priority: Blocker Affects Version/s: 0.9.6 I am assigning this Issue to version 0.9.7, although it really doesn't require a change in the OpenJPA code. This Issue is dependent on a change in the WebSphere code that should be in the Beta release for the EJB3/JPA Feature Pack. I will also assign this Issue to myself for tracking purposes. non-jta-data-source must be specified in WebSphere environments --- Key: OPENJPA-149 URL: https://issues.apache.org/jira/browse/OPENJPA-149 Project: OpenJPA Issue Type: Improvement Components: kernel Affects Versions: 0.9.6 Environment: WebSphere Reporter: Patrick Linskey Assigned To: Kevin Sutter Priority: Blocker Fix For: 0.9.7 The suspend(), resume(), begin(), and commit() methods in org.apache.openjpa.ee.WASManagedRuntime$WASTransaction all throw exceptions. This prevents the logic in org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq from executing. See OPENJPA-144 for relevant stack traces. In particular, look at the Only-JTASpecified.txt trace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-5) OpenJPA doesn't compile with JDBC 4
[ https://issues.apache.org/jira/browse/OPENJPA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter updated OPENJPA-5: --- Fix Version/s: 1.0.0 Affects Version/s: 0.9.0 0.9.6 OpenJPA doesn't compile with JDBC 4 --- Key: OPENJPA-5 URL: https://issues.apache.org/jira/browse/OPENJPA-5 Project: OpenJPA Issue Type: Improvement Components: build / infrastructure Affects Versions: 0.9.0, 0.9.6 Reporter: Craig Russell Fix For: 1.0.0 Patrick opines: OpenJPA implements Statement, ResultSet, Connection, and maybe a couple other JDBC interfaces. See org.apache.openjpa.lib.jdbc.Delegating*. We do this for a number of reasons: to resolve database-specific bugs in a transparent fashion, to provide logging, to handle reference counting, etc. The pressing issue is that we must provide implementations of all of the methods in the various java.sql interfaces. The fact that we do not implement the new JDBC4 methods is why OpenJPA won't currently compile against JDK6. This is pretty easy to fix; take a look at org.apache.openjpa.lib.jdbc.DelegatingStatement to see how we handled this for JDBC3. Since we know that we never invoke the new methods, we can happily throw unsupported operation exceptions for the new methods. However, these unsupported methods do provide a challenge. While Kodo doesn't use any of these methods, our mechanism for implementing them is limiting, in that users who obtain Connections from Kodo will not be able to use the new JDBC3/JDBC4 methods in their own code. Ideally, we should provide some means for people to designate to OpenJPA that it should use a dynamic proxy to implement the unimplemented methods. This shouldn't be the default behavior, as the dynamic proxy will add overhead, but certainly could be desirable for some. I'll file an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-165) QueryImpl.setFirstResult does not take already set maxResults into account
[ https://issues.apache.org/jira/browse/OPENJPA-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter reassigned OPENJPA-165: Assignee: Kevin Sutter QueryImpl.setFirstResult does not take already set maxResults into account -- Key: OPENJPA-165 URL: https://issues.apache.org/jira/browse/OPENJPA-165 Project: OpenJPA Issue Type: Bug Components: query Affects Versions: 0.9.7 Reporter: Jonathan Feinberg Assigned To: Kevin Sutter If you want rows 10-19 of some query, the sequence q.setFirstResult(10).setMaxResults(10); behaves as expected. On the other hand q.setMaxResults(10).setFirstResult(10); returns the empty list. QueryImpl.setFirstResult should reset the range endpoint. maxResults is a count, not an index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-165) QueryImpl.setFirstResult does not take already set maxResults into account
[ https://issues.apache.org/jira/browse/OPENJPA-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter updated OPENJPA-165: - Fix Version/s: 0.9.7 I've discussed this problem with Jonathan and we should have a patch available soon. QueryImpl.setFirstResult does not take already set maxResults into account -- Key: OPENJPA-165 URL: https://issues.apache.org/jira/browse/OPENJPA-165 Project: OpenJPA Issue Type: Bug Components: query Affects Versions: 0.9.7 Reporter: Jonathan Feinberg Assigned To: Kevin Sutter Fix For: 0.9.7 If you want rows 10-19 of some query, the sequence q.setFirstResult(10).setMaxResults(10); behaves as expected. On the other hand q.setMaxResults(10).setFirstResult(10); returns the empty list. QueryImpl.setFirstResult should reset the range endpoint. maxResults is a count, not an index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Java 2 Security testing?
Just curious, Has there been any testing with Java 2 Security enabled and OpenJPA? I'm hitting a semi-intermittent problem (it doesn't seem to show up on all machines) which results in an NPE coming out of the javax.persistence.Persistence.createEntityManager method. I know we have no control over this specific piece of code, but I'm wondering whether we need some doPriv blocks elsewhere in the code path. I reviewed the JIRA Issues and didn't see anything related to this. Before I go further, I thought I would check to see if there's been any other experiences with Java 2 Security. Thanks. Kevin P.S. Here's the call stack if you are interested... Caused by: java.lang.NullPointerException at java.io.Win32CanonicalPathComponentRetriever.nextComponent( Win32CanonicalPath.java:318) at java.io.Win32CanonicalPath.equals(Win32CanonicalPath.java:117) at java.io.FilePermission.impliesIgnoreMask(FilePermission.java:373) at java.io.FilePermissionCollection.implies(FilePermission.java:763) at org.eclipse.osgi.framework.internal.core.ConditionalPermissionSet.implies( ConditionalPermissionSet.java:224) at org.eclipse.osgi.framework.internal.core.BundleCombinedPermissions.implies( BundleCombinedPermissions.java:124) at java.security.ProtectionDomain.implies(ProtectionDomain.java:225) at java.security.AccessController.checkPermission(AccessController.java :94) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at com.ibm.ws.security.core.SecurityManager.checkPermission( SecurityManager.java:189) at java.lang.SecurityManager.checkRead(SecurityManager.java:886) at java.io.File.exists(File.java:726) at org.apache.openjpa.lib.meta.URLMetaDataIterator.getFile( URLMetaDataIterator.java:68) at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse( XMLMetaDataParser.java:311) at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse( XMLMetaDataParser.java:289) at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse( XMLMetaDataParser.java:263) at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationParser.parse (PersistenceProductDerivation.java:419) at org.apache.openjpa.persistence.PersistenceProductDerivation.parseResources( PersistenceProductDerivation.java:287) at org.apache.openjpa.persistence.PersistenceProductDerivation.load( PersistenceProductDerivation.java:254) at org.apache.openjpa.persistence.PersistenceProductDerivation.load( PersistenceProductDerivation.java:152) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory (PersistenceProviderImpl.java:66) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory (PersistenceProviderImpl.java:78) at javax.persistence.Persistence.createEntityManagerFactory( Persistence.java:83) at javax.persistence.Persistence.createEntityManagerFactory( Persistence.java:60)
[jira] Created: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
EntityManager.getReference() returns an object of a wronc class --- Key: OPENJPA-171 URL: https://issues.apache.org/jira/browse/OPENJPA-171 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.6 Reporter: Stefano Juri I have a simple class system : a PersonImpl owns a set of AbstractAddresses. An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All these objects extend AbstractBusinessObject. When I call entityManager.getReference(PersonImpl.class, 1) I get the EMailAddressImpl object with id 1 instead of a PersonImpl object. If I get the object with a query (select p from PersonImpl p where p.id='1') everything is ok. My mapping file is : 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 http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 !-- mapped-superclass class=ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl attributes id name=id column name=ID / generated-value strategy=SEQUENCE generator=TimeSeq/ sequence-generator name=TimeSeq sequence-name=time()/ /id version name=version / /attributes /mapped-superclass -- entity class=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl table name=ADDRESS/table inheritance strategy=SINGLE_TABLE/ discriminator-column name=DISCRIMINANT length=1/ attributes basic name=addressName column name=ADDRESS_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.EMailAddressImpl discriminator-valueE/discriminator-value attributes basic name=domain column name=EMAIL_DOMAIN/ /basic basic name=name column name=EMAIL_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.PostalAddressImpl discriminator-valueP/discriminator-value attributes basic name=firstName column name=FIRST_NAME/ /basic basic name=lastName column name=LAST_NAME/ /basic basic name=street/basic basic name=country/basic basic name=zip/basic basic name=city/basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.person.PersonImpl table name=PERSON / attributes basic name=title / basic name=firstName column name=FIRST_NAME / /basic basic name=lastName column name=LAST_NAME / /basic one-to-many name=addresses target-entity=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl join-table name=PERS_ADDR join-column name=ID_PERSON / inverse-join-column name=ID_ADDRESS / /join-table /one-to-many /attributes /entity /entity-mappings And the database creation script is : -- -- Create Table ADDRESS -- Create table ADDRESS ( ID VARCHAR(20) NOT NULL, DISCRIMINANT CHARACTER(1)NOT NULL, ADDRESS_NAME VARCHAR(35) NOT NULL, EMAIL_DOMAIN VARCHAR(50) , EMAIL_NAME VARCHAR(50) , FIRST_NAME VARCHAR(35) , LAST_NAME VARCHAR(35) , STREET VARCHAR(35) , CITY VARCHAR(35) , ZIPVARCHAR(10)
Re: OpenJPA love
The primary reason was the license, Hibernate is LGPL and it's not compatible with the Apache license. But we've found some other benefits during the migration. For us an important one is the good control OpenJPA gives you on the flush. Theoretically you can do the same thing with Hibernate but practically when you're in a JTA environment it just flushes whenever it wants (depending on the queries you execute). If you don't flush exclusively at the end of the transaction you can very quickly run into very hard to solve deadlocks with some non MVCC databases (thinking mostly of SQL Server 2000 here). Cheers, Matthieu On 3/12/07, Hans J. Prueller [EMAIL PROTECTED] wrote: Any special reason why you have been migrating from Hibernate to OpenJPA (in addition to that it is an Apache project)? regards, hans -Ursprüngliche Nachricht- Von: Matthieu Riou [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 13. März 2007 03:33 An: open-jpa-dev@incubator.apache.org Betreff: OpenJPA love Hi guys, Just a quick note to let you know we've completed the migration of Apache ODE from Hibernate to OpenJPA. Everything seem to work pretty well now. I expect a few glitches here and there as we run in heavily parallelized environments but the transition has been pretty smooth. Thanks a lot for your help and all the good work! The ODE team.
OpenJPA error with NamedNativeQuery
Hi,
John is having some problems with posting to the open-jpa-dev mailing list
via his e-mail account, so I am posting this message for him so that we can
start this conversation...
=
Fellow OpenJPAers, :)
As Craig had brought up (through Scott Oaks) a while ago and Patrick was
privy to on a discussion with a benchmarking organization we needed a
mechanism to implement pessimistic locking in some fashion under certain
circumstances inside of our current optimistic world. We decided at that
time that the only really portable way to do this at the moment was to
create a named query in the benchmark that could then be overridden in the
ORM.xml file. Well I took that at face value and started pushing the
methodology on the folks working on DayTrader for Apache and today we found
out that you cannot issue a select for update query with either the Oracle
Toplink RI or OpenJPA 0.9.7-inc builds at this time. Maybe I am just
missing something in our approach but we decided to leave out the
ORM.xmlmapping and just use a native named query in the code for
DayTrader just to
get it off the ground and running. Code snipit below:
Native named Query defined as this:
@NamedNativeQueries({
@NamedNativeQuery(name=quoteForUpdate, query=select * from quoteejb q
where q.symbol=? for update,resultClass=
org.apache.geronimo.samples.daytrader.Quoteejb.class)
})
EJB method calling is this:
public Quoteejb testForUpdateQuery(String symbol){
Query q = em.createNativeQuery(quoteForUpdate);
q.setParameter(1,symbol);
//Quoteejb temp = (Quoteejb) q.getSingleResult();
Quoteejb temp = (Quoteejb) q.getResultList().get(0);
temp.setCompanyname(IBM_+System.currentTimeMillis());
return em.merge(temp);
}
This code produces the following errors on Toplink and on OpenJPA
Toplink:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8 (Build
060830)): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.ibm.db2.jcc.c.SqlException:
[ibm][db2][jcc][10103][10941] Method executeQuery cannot be used for
update.Error Code: -9
Call:quoteForUpdate
Query:DataReadQuery()
at oracle.toplink.essentials.exceptions.DatabaseException.sqlException(
DatabaseException.java:303)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall
(DatabaseAccessor.java:551)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeCall
(DatabaseAccessor.java:437)
at oracle.toplink.essentials.threetier.ServerSession.executeCall(
ServerSession.java:465)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall
(DatasourceCallQueryMechanism.java:213)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall
(DatasourceCallQueryMechanism.java:199)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeSelectCall
(DatasourceCallQueryMechanism.java:270)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeSelect
(DatasourceCallQueryMechanism.java:252)
OpenJPA:Caused by: 4|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.InvalidStateException: Cannot perform a
select on update or delete query: quoteForUpdate.
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:215)
at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java
:264)
at com.ibm.performance.primitives.jee5.ejb.QuoteejbFacade.testForUpdateQuery
(QuoteejbFacade.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(
EJBSecurityManager.java:1050)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(
BaseContainer.java:2766)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(
EJBLocalObjectInvocationHandler.java:184)
... 30 more
This query works perfectly fine in a straight up JDBC case so I can't see
why it wouldn't work here.
Looking forward to any responses. Would be happy if it was something the
folks building DayTrader were doing wrong with the code but I think it might
be a OpenJPA issue.
Sincerely,
John
Re: OpenJPA error with NamedNativeQuery
I am fairly certain that the only way OpenJPA will ever think that a
native (i.e., SQL) query is not a select query is if it doesn't start
with select.
Is it possible that you didn't recompile the class after
experimenting with the quoteForUpdate @NamedNativeQuery? At some
point in the past, did the query string start with update?
On Mar 13, 2007, at 8:25 AM, Kevin Sutter wrote:
Hi,
John is having some problems with posting to the open-jpa-dev
mailing list
via his e-mail account, so I am posting this message for him so
that we can
start this conversation...
=
Fellow OpenJPAers, :)
As Craig had brought up (through Scott Oaks) a while ago and
Patrick was
privy to on a discussion with a benchmarking organization we needed a
mechanism to implement pessimistic locking in some fashion under
certain
circumstances inside of our current optimistic world. We decided
at that
time that the only really portable way to do this at the moment was to
create a named query in the benchmark that could then be overridden
in the
ORM.xml file. Well I took that at face value and started pushing the
methodology on the folks working on DayTrader for Apache and today
we found
out that you cannot issue a select for update query with either the
Oracle
Toplink RI or OpenJPA 0.9.7-inc builds at this time. Maybe I am just
missing something in our approach but we decided to leave out the
ORM.xmlmapping and just use a native named query in the code for
DayTrader just to
get it off the ground and running. Code snipit below:
Native named Query defined as this:
@NamedNativeQueries({
@NamedNativeQuery(name=quoteForUpdate, query=select * from
quoteejb q
where q.symbol=? for update,resultClass=
org.apache.geronimo.samples.daytrader.Quoteejb.class)
})
EJB method calling is this:
public Quoteejb testForUpdateQuery(String symbol){
Query q = em.createNativeQuery(quoteForUpdate);
q.setParameter(1,symbol);
//Quoteejb temp = (Quoteejb) q.getSingleResult();
Quoteejb temp = (Quoteejb) q.getResultList().get(0);
temp.setCompanyname(IBM_+System.currentTimeMillis());
return em.merge(temp);
}
This code produces the following errors on Toplink and on OpenJPA
Toplink:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8 (Build
060830)): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.ibm.db2.jcc.c.SqlException:
[ibm][db2][jcc][10103][10941] Method executeQuery cannot be used for
update.Error Code: -9
Call:quoteForUpdate
Query:DataReadQuery()
at
oracle.toplink.essentials.exceptions.DatabaseException.sqlException(
DatabaseException.java:303)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.bas
icExecuteCall
(DatabaseAccessor.java:551)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.exe
cuteCall
(DatabaseAccessor.java:437)
at oracle.toplink.essentials.threetier.ServerSession.executeCall(
ServerSession.java:465)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryM
echanism.executeCall
(DatasourceCallQueryMechanism.java:213)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryM
echanism.executeCall
(DatasourceCallQueryMechanism.java:199)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryM
echanism.executeSelectCall
(DatasourceCallQueryMechanism.java:270)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryM
echanism.executeSelect
(DatasourceCallQueryMechanism.java:252)
OpenJPA:Caused by: 4|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.InvalidStateException: Cannot perform a
select on update or delete query: quoteForUpdate.
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:
215)
at org.apache.openjpa.persistence.QueryImpl.getResultList
(QueryImpl.java
:264)
at
com.ibm.performance.primitives.jee5.ejb.QuoteejbFacade.testForUpdateQu
ery
(QuoteejbFacade.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java
:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(
EJBSecurityManager.java:1050)
at com.sun.enterprise.security.SecurityUtil.invoke
(SecurityUtil.java:165)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(
BaseContainer.java:2766)
at com.sun.ejb.containers.BaseContainer.intercept
(BaseContainer.java:3847)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(
EJBLocalObjectInvocationHandler.java:184)
... 30 more
This query works perfectly fine in a straight up JDBC case so I
can't see
why it wouldn't work here.
Looking forward to any responses. Would be happy if it was
something the
folks building DayTrader were doing wrong with the code but I
Re: JOIN in subselect problems
Roger-
The query looks valid: it sounds like a pretty clear-cut bug. Can you
file a JIRA?
As for a workaround, is there an inverse from MailingList.subscribers
(e.g., Email.mailingList)? If so, then you might be able to re-cast
the query as:
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM Email m where m.mailingList IS NOT NULL)
On Mar 13, 2007, at 2:04 AM, roger.keays wrote:
Is there anything wrong with the following query?
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM MailingList l JOIN l.subscribers m)
OpenJPA (0.9.6) parses this correctly, but can't seems to be
missing the
JOIN clause or some table names from the generated SQL:
org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: syntax
error at
or near WHERE {prepstmnt 27475707 UPDATE FB_EMAILS SET
totalDeliveries =
(totalDeliveries + ?) WHERE email IN (SELECT DISTINCT t2.email FROM
WHERE
(t2.email IN (SELECT t3.email FROM FB_EMAILS t3 WHERE t0.id = t1.id
AND
t1.subscribers_email = t3.email))) [params=(long) 1]} [code=0,
state=42601]
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap
(LoggingConnectionDecorator.java:188)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$800
(LoggingConnectionDecorator.java:53)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator
$LoggingConnection$LoggingPreparedStatement.executeUpdate
(LoggingConnectionDecorator.java:854)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(
DelegatingPreparedStatement.java:266)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(
DelegatingPreparedStatement.java:266)
org.apache.openjpa.jdbc.kernel.JDBCStoreManager
$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1360)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation
(JDBCStoreQuery.java:491)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate
(JDBCStoreQuery.java:420)
org.apache.openjpa.kernel.ExpressionStoreQuery
$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:685)
org.apache.openjpa.datacache.QueryCacheStoreQuery
$QueryCacheExecutor.executeUpdate(QueryCacheStoreQuery.java:343)
org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1028)
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:793)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:868)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:864)
org.apache.openjpa.kernel.DelegatingQuery.updateAll
(DelegatingQuery.java:560)
org.apache.openjpa.persistence.QueryImpl.executeUpdate
(QueryImpl.java:304)
Thanks,
Roger
--
View this message in context: http://www.nabble.com/JOIN-in-
subselect-problems-tf3394694.html#a9450588
Sent from the open-jpa-dev mailing list archive at Nabble.com.
[jira] Commented: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
[ https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480455 ] Abe White commented on OPENJPA-171: --- It would speed things up a lot if you attached a working test case demonstrating the problem. EntityManager.getReference() returns an object of a wronc class --- Key: OPENJPA-171 URL: https://issues.apache.org/jira/browse/OPENJPA-171 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.6 Reporter: Stefano Juri I have a simple class system : a PersonImpl owns a set of AbstractAddresses. An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All these objects extend AbstractBusinessObject. When I call entityManager.getReference(PersonImpl.class, 1) I get the EMailAddressImpl object with id 1 instead of a PersonImpl object. If I get the object with a query (select p from PersonImpl p where p.id='1') everything is ok. My mapping file is : 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 http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 mapped-superclass class=ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl attributes id name=id column name=ID / generated-value strategy=SEQUENCE generator=TimeSeq/ sequence-generator name=TimeSeq sequence-name=time()/ /id version name=version / /attributes /mapped-superclass entity class=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl table name=ADDRESS/table inheritance strategy=SINGLE_TABLE/ discriminator-column name=DISCRIMINANT length=1/ attributes basic name=addressName column name=ADDRESS_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.EMailAddressImpl discriminator-valueE/discriminator-value attributes basic name=domain column name=EMAIL_DOMAIN/ /basic basic name=name column name=EMAIL_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.PostalAddressImpl discriminator-valueP/discriminator-value attributes basic name=firstName column name=FIRST_NAME/ /basic basic name=lastName column name=LAST_NAME/ /basic basic name=street/basic basic name=country/basic basic name=zip/basic basic name=city/basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.person.PersonImpl table name=PERSON / attributes basic name=title / basic name=firstName column name=FIRST_NAME / /basic basic name=lastName column name=LAST_NAME / /basic one-to-many name=addresses target-entity=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl join-table name=PERS_ADDR join-column name=ID_PERSON / inverse-join-column name=ID_ADDRESS / /join-table /one-to-many /attributes /entity /entity-mappings And the database creation script is : -- -- Create Table ADDRESS -- Create table ADDRESS ( ID VARCHAR(20) NOT NULL, DISCRIMINANT CHARACTER(1)NOT NULL, ADDRESS_NAME VARCHAR(35) NOT NULL, EMAIL_DOMAIN VARCHAR(50) , EMAIL_NAME VARCHAR(50) , FIRST_NAME VARCHAR(35) ,
Re: OpenJPA error with NamedNativeQuery
John-
I just ran a test with a named native query that did a select ...
for update and it worked fine.
One possibility is that our identification of whether the native
query is a select or an update is done by some fairly simplistic
parsing of whether the statement starts with select or not. Is it
possible there is some extra hidden character in the string? If you
delete the NamedNativeQuery line and re-type it, do you still get the
same error?
If that doesn't help, can we try to narrow down the problem by
bypassing the named query and trying to just execute the query
directly? E.g., do the following:
em.createNativeQuery(select * from quoteejb q where q.symbol=? for
update).setParameter(1, SYMBOL).getResultList();
On Mar 13, 2007, at 11:03 AM, John Stecher wrote:
Marc,
I know that we recompiled the classes multiple times and I also
know that the query is a correct/working for DB2 when running in a
JDBC environment. The statement never started with update. I
wouldn't expect that OpenJPA would be attempting to dictate what
type of query I am running in a native sql statement by it
syntax. How are others doing this select for update on a finder?
A pure update doesn't work as it would not allow me to hold the
lock on the database. Patrick had said that this should work with
Kodo in our benchmarking disucssion (as did Mike Keith for Toplink)
so I am interested to see if it is in some manner working with a
test case that I am not privy to.
Any help would be greatly appreciated as I believe this is a gating
factor for us moving forward testing the SPEC benchmarks as well as
DayTrader being developed for Apache.
John
On 3/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
I am fairly certain that the only way OpenJPA will ever think that a
native (i.e., SQL) query is not a select query is if it doesn't start
with select.
Is it possible that you didn't recompile the class after
experimenting with the quoteForUpdate @NamedNativeQuery? At some
point in the past, did the query string start with update?
On Mar 13, 2007, at 8:25 AM, Kevin Sutter wrote:
Hi,
John is having some problems with posting to the open-jpa-dev
mailing list
via his e-mail account, so I am posting this message for him so
that we can
start this conversation...
=
Fellow OpenJPAers, :)
As Craig had brought up (through Scott Oaks) a while ago and
Patrick was
privy to on a discussion with a benchmarking organization we
needed a
mechanism to implement pessimistic locking in some fashion under
certain
circumstances inside of our current optimistic world. We decided
at that
time that the only really portable way to do this at the moment
was to
create a named query in the benchmark that could then be overridden
in the
ORM.xml file. Well I took that at face value and started pushing
the
methodology on the folks working on DayTrader for Apache and today
we found
out that you cannot issue a select for update query with either the
Oracle
Toplink RI or OpenJPA 0.9.7-inc builds at this time. Maybe I am
just
missing something in our approach but we decided to leave out the
ORM.xmlmapping and just use a native named query in the code for
DayTrader just to
get it off the ground and running. Code snipit below:
Native named Query defined as this:
@NamedNativeQueries({
@NamedNativeQuery(name=quoteForUpdate, query=select * from
quoteejb q
where q.symbol=? for update,resultClass=
org.apache.geronimo.samples.daytrader.Quoteejb.class)
})
EJB method calling is this:
public Quoteejb testForUpdateQuery(String symbol){
Query q = em.createNativeQuery(quoteForUpdate);
q.setParameter(1,symbol);
//Quoteejb temp = (Quoteejb) q.getSingleResult();
Quoteejb temp = (Quoteejb) q.getResultList().get(0);
temp.setCompanyname(IBM_+System.currentTimeMillis());
return em.merge(temp);
}
This code produces the following errors on Toplink and on OpenJPA
Toplink:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8 (Build
060830)): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.ibm.db2.jcc.c.SqlException :
[ibm][db2][jcc][10103][10941] Method executeQuery cannot be used for
update.Error Code: -9
Call:quoteForUpdate
Query:DataReadQuery()
at
oracle.toplink.essentials.exceptions.DatabaseException.sqlException (
DatabaseException.java:303)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.bas
icExecuteCall
(DatabaseAccessor.java:551)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.exe
cuteCall
(DatabaseAccessor.java:437)
at oracle.toplink.essentials.threetier.ServerSession.executeCall(
ServerSession.java:465)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryM
echanism.executeCall
(DatasourceCallQueryMechanism.java:213)
at
Re: OpenJPA error with NamedNativeQuery
Hi John,
EJB method calling is this:
public Quoteejb testForUpdateQuery(String symbol){
Query q = em.createNativeQuery("quoteForUpdate");
q.setParameter(1,symbol);
Shouldn't you call Query q = em.createNativeNamedQuery("quoteForUpdate");
?
Regards,
Mitesh
Marc Prud'hommeaux wrote:
John-
I just ran a test with a named native query that did a "select ... for
update" and it worked fine.
One possibility is that our identification of whether the native query
is a select or an update is done by some fairly simplistic parsing of
whether the statement starts with "select" or not. Is it possible there
is some extra hidden character in the string? If you delete the
NamedNativeQuery line and re-type it, do you still get the same error?
If that doesn't help, can we try to narrow down the problem by
bypassing the named query and trying to just execute the query
directly? E.g., do the following:
em.createNativeQuery("select * from quoteejb q where q.symbol=? for
update").setParameter(1, "SYMBOL").getResultList();
On Mar 13, 2007, at 11:03 AM, John Stecher wrote:
Marc,
I know that we recompiled the classes multiple times and I also know
that the query is a correct/working for DB2 when running in a JDBC
environment. The statement never started with update. I wouldn't
expect that OpenJPA would be attempting to dictate what type of query I
am running in a native sql statement by it syntax. How are others
doing this select for update on a finder? A pure update doesn't work
as it would not allow me to hold the lock on the database. Patrick had
said that this should work with Kodo in our benchmarking disucssion (as
did Mike Keith for Toplink) so I am interested to see if it is in some
manner working with a test case that I am not privy to.
Any help would be greatly appreciated as I believe this is a gating
factor for us moving forward testing the SPEC benchmarks as well as
DayTrader being developed for Apache.
John
On 3/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
I am fairly certain that the only way OpenJPA will ever think that a
native (i.e., SQL) query is not a select query is if it doesn't start
with "select".
Is it possible that you didn't recompile the class after
experimenting with the "quoteForUpdate" @NamedNativeQuery? At some
point in the past, did the query string start with "update"?
On Mar 13, 2007, at 8:25 AM, Kevin Sutter wrote:
Hi,
John is having some problems with posting to the open-jpa-dev
mailing list
via his e-mail account, so I am posting this message for him so
that we can
start this conversation...
=
Fellow OpenJPAers, :)
As Craig had brought up (through Scott Oaks) a while ago and
Patrick was
privy to on a discussion with a benchmarking organization we
needed a
mechanism to implement pessimistic locking in some fashion under
certain
circumstances inside of our current optimistic world. We decided
at that
time that the only really portable way to do this at the moment
was to
create a named query in the benchmark that could then be
overridden
in the
ORM.xml file. Well I took that at face value and started pushing
the
methodology on the folks working on DayTrader for Apache and today
we found
out that you cannot issue a select for update query with either
the
Oracle
Toplink RI or OpenJPA 0.9.7-inc builds at this time. Maybe I am
just
missing something in our approach but we decided to leave out the
ORM.xmlmapping and just use a native named query in the code for
DayTrader just to
get it off the ground and running. Code snipit below:
Native named Query defined as this:
@NamedNativeQueries({
@NamedNativeQuery(name="quoteForUpdate", query="select * from
quoteejb q
where q.symbol=? for update",resultClass=
org.apache.geronimo.samples.daytrader.Quoteejb.class)
})
EJB method calling is this:
public Quoteejb testForUpdateQuery(String symbol){
Query q = em.createNativeQuery("quoteForUpdate");
q.setParameter(1,symbol);
//Quoteejb temp = (Quoteejb) q.getSingleResult();
Quoteejb temp = (Quoteejb) q.getResultList().get(0);
temp.setCompanyname("IBM_"+System.currentTimeMillis());
return em.merge(temp);
}
This code produces the following errors on Toplink and on OpenJPA
Toplink:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8
(Build
060830)): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.ibm.db2.jcc.c.SqlException :
[ibm][db2][jcc][10103][10941] Method executeQuery cannot be used
for
update.Error Code: -9
[jira] Commented: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
[ https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480510 ] Abe White commented on OPENJPA-171: --- I attempted to reproduce this in a very simple test case but failed. We'll need a user-supplied test case. As a technical aside, I'm having trouble seeing how the T getReference(ClassT cls, Object id) method could possibly return anything other than a T instance. EntityManager.getReference() returns an object of a wronc class --- Key: OPENJPA-171 URL: https://issues.apache.org/jira/browse/OPENJPA-171 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.6 Reporter: Stefano Juri I have a simple class system : a PersonImpl owns a set of AbstractAddresses. An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All these objects extend AbstractBusinessObject. When I call entityManager.getReference(PersonImpl.class, 1) I get the EMailAddressImpl object with id 1 instead of a PersonImpl object. If I get the object with a query (select p from PersonImpl p where p.id='1') everything is ok. My mapping file is : 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 http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; version=1.0 mapped-superclass class=ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl attributes id name=id column name=ID / generated-value strategy=SEQUENCE generator=TimeSeq/ sequence-generator name=TimeSeq sequence-name=time()/ /id version name=version / /attributes /mapped-superclass entity class=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl table name=ADDRESS/table inheritance strategy=SINGLE_TABLE/ discriminator-column name=DISCRIMINANT length=1/ attributes basic name=addressName column name=ADDRESS_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.EMailAddressImpl discriminator-valueE/discriminator-value attributes basic name=domain column name=EMAIL_DOMAIN/ /basic basic name=name column name=EMAIL_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.PostalAddressImpl discriminator-valueP/discriminator-value attributes basic name=firstName column name=FIRST_NAME/ /basic basic name=lastName column name=LAST_NAME/ /basic basic name=street/basic basic name=country/basic basic name=zip/basic basic name=city/basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.person.PersonImpl table name=PERSON / attributes basic name=title / basic name=firstName column name=FIRST_NAME / /basic basic name=lastName column name=LAST_NAME / /basic one-to-many name=addresses target-entity=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl join-table name=PERS_ADDR join-column name=ID_PERSON / inverse-join-column name=ID_ADDRESS / /join-table /one-to-many /attributes /entity /entity-mappings And the database creation script is : -- -- Create Table ADDRESS -- Create table ADDRESS ( ID VARCHAR(20) NOT NULL, DISCRIMINANT CHARACTER(1)NOT NULL, ADDRESS_NAME VARCHAR(35) NOT NULL, EMAIL_DOMAIN VARCHAR(50)
Re: JOIN in subselect problems
Roger,
There is a similar problem already reported under bug OPENJPA-51.
Catalina
On 3/13/07, roger.keays [EMAIL PROTECTED] wrote:
Is there anything wrong with the following query?
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM MailingList l JOIN l.subscribers m)
OpenJPA (0.9.6) parses this correctly, but can't seems to be missing the
JOIN clause or some table names from the generated SQL:
org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: syntax error at
or near WHERE {prepstmnt 27475707 UPDATE FB_EMAILS SET totalDeliveries =
(totalDeliveries + ?) WHERE email IN (SELECT DISTINCT t2.email FROM WHERE
(t2.email IN (SELECT t3.email FROM FB_EMAILS t3 WHERE t0.id = t1.id AND
t1.subscribers_email = t3.email))) [params=(long) 1]} [code=0,
state=42601]
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
LoggingConnectionDecorator.java:188)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$800(
LoggingConnectionDecorator.java:53)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate
(LoggingConnectionDecorator.java:854)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(
DelegatingPreparedStatement.java:266)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(
DelegatingPreparedStatement.java:266)
org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate
(JDBCStoreManager.java:1360)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation(
JDBCStoreQuery.java:491)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate(
JDBCStoreQuery.java:420)
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeUpdate
(ExpressionStoreQuery.java:685)
org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeUpdate
(QueryCacheStoreQuery.java:343)
org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1028)
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:793)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:868)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:864)
org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java
:560)
org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:304)
Thanks,
Roger
--
View this message in context:
http://www.nabble.com/JOIN-in-subselect-problems-tf3394694.html#a9450588
Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Java 2 Security testing?
Marc, On 3/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Kevin- I don't think we've done extensive stand-alone testing with security enabled, but we have people using OpenJPA in so many different exotic containers with their attendant security settings, that I'd be a little surprised if there were essential doPriv checks that were missing. I agree. This is kind of convoluted environment. We have WebSphere 6.1with Spring (not sure of the version) and OpenJPA 0.9.7 nightly. The fact that it is an intermittent NPE from java.io.Win32CanonicalPathComponentRetriever gives me a little pause. Which JVM did you test on? Maybe intermittent isn't the right word. It's really where we run into the problem on one machine and not another. But, the visual inspection indicates that the environments are the same. The current testing is with the IBM JDK 5.0 SR3. We will also check out the latest SR4 and the Sun JDK to see if the results change. Also, it'd be nice to figure out what that file name being passed to File.exists() is. A println on the file name in URLMetaDataIterator.getFile() might show that it is a string with such crazy characters that it triggers some other bug with Windows file handing. Good idea. I was assuming that it was a standard file (ie. persistence.xml). Let me try that as well. Kevin On Mar 13, 2007, at 5:55 AM, Kevin Sutter wrote: Just curious, Has there been any testing with Java 2 Security enabled and OpenJPA? I'm hitting a semi-intermittent problem (it doesn't seem to show up on all machines) which results in an NPE coming out of the javax.persistence.Persistence.createEntityManager method. I know we have no control over this specific piece of code, but I'm wondering whether we need some doPriv blocks elsewhere in the code path. I reviewed the JIRA Issues and didn't see anything related to this. Before I go further, I thought I would check to see if there's been any other experiences with Java 2 Security. Thanks. Kevin P.S. Here's the call stack if you are interested... Caused by: java.lang.NullPointerException at java.io.Win32CanonicalPathComponentRetriever.nextComponent( Win32CanonicalPath.java:318) at java.io.Win32CanonicalPath.equals(Win32CanonicalPath.java:117) at java.io.FilePermission.impliesIgnoreMask(FilePermission.java: 373) at java.io.FilePermissionCollection.implies(FilePermission.java: 763) at org.eclipse.osgi.framework.internal.core.ConditionalPermissionSet.impl ies( ConditionalPermissionSet.java:224) at org.eclipse.osgi.framework.internal.core.BundleCombinedPermissions.imp lies( BundleCombinedPermissions.java:124) at java.security.ProtectionDomain.implies(ProtectionDomain.java: 225) at java.security.AccessController.checkPermission (AccessController.java :94) at java.lang.SecurityManager.checkPermission (SecurityManager.java:547) at com.ibm.ws.security.core.SecurityManager.checkPermission( SecurityManager.java:189) at java.lang.SecurityManager.checkRead(SecurityManager.java:886) at java.io.File.exists(File.java:726) at org.apache.openjpa.lib.meta.URLMetaDataIterator.getFile( URLMetaDataIterator.java:68) at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse( XMLMetaDataParser.java:311) at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse( XMLMetaDataParser.java:289) at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse( XMLMetaDataParser.java:263) at org.apache.openjpa.persistence.PersistenceProductDerivation $ConfigurationParser.parse (PersistenceProductDerivation.java:419) at org.apache.openjpa.persistence.PersistenceProductDerivation.parseResou rces( PersistenceProductDerivation.java:287) at org.apache.openjpa.persistence.PersistenceProductDerivation.load( PersistenceProductDerivation.java:254) at org.apache.openjpa.persistence.PersistenceProductDerivation.load( PersistenceProductDerivation.java:152) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityMan agerFactory (PersistenceProviderImpl.java:66) at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityMan agerFactory (PersistenceProviderImpl.java:78) at javax.persistence.Persistence.createEntityManagerFactory( Persistence.java:83) at javax.persistence.Persistence.createEntityManagerFactory( Persistence.java:60)
[jira] Created: (OPENJPA-172) DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.
DSRA9250E: Operation setTransactionIsolation is not allowed during a global
transaction for Shareable Connections.
---
Key: OPENJPA-172
URL: https://issues.apache.org/jira/browse/OPENJPA-172
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.6
Environment: Websphere 6.1 for zos and DB2 zos V8
Reporter: Ritika Maheshwari
Fix For: 0.9.6
My persistence.xml looks like following
***
?xml version=1.0 ?
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
version=1.0
persistence-unit name=dwtest transaction-type=JTA
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
non-jta-data-sourcejdbc/ErwwDS/non-jta-data-source
classejb.jpa.test.Customer/class
classejb.jpa.test.District/class
classejb.jpa.test.Warehouse/class
classejb.jpa.test.History/class
classejb.jpa.test.Item/class
classejb.jpa.test.Neworders/class
classejb.jpa.test.Orderline/class
classejb.jpa.test.Orders/class
classejb.jpa.test.Stock/class
properties
property name=openjpa.LockManager value=pessimistic/
property name=openjpa.ReadLockLevel value=read/
property name=openjpa.WriteLockLevel value=write/
property name=openjpa.LockTimeout value=3/
property name=openjpa.FetchBatchSize value=1 /
property name=openjpa.jdbc.TransactionIsolation value=read-committed /
property name=openjpa.Log value=DefaultLevel=WARN, Runtime=INFO,
Tool=INFO,SQL=TRACE/
/properties
/persistence-unit
/persistence
***
The Orderline entity looks like following
*
@Entity
@IdClass(ejb.jpa.test.OrderlineId.class)
@SequenceGenerator(name=mysequence,sequenceName=ORDER_ID)
public class Orderline implements Serializable{
@Id
@GeneratedValue(strategy=GenerationType.SEQUENCE,generator=mysequence)
java.lang.Integer ol_o_id = null;
@Id
java.lang.String ol_d_id = null;
@Id
java.lang.String ol_w_id = null;
@Id
java.lang.Short ol_number = null;
java.lang.String ol_i_id = null;
java.sql.Timestamp ol_delivery_d = null;
java.lang.String ol_supply_w_id = null;
java.lang.Short ol_quantity = null;
java.math.BigDecimal ol_amount = null;
java.sql.Timestamp itime = null;
java.lang.String ol_dist_info = null;
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns({
@JoinColumn(name=ol_o_id, referencedColumnName=o_id),
@JoinColumn(name=ol_d_id, referencedColumnName=o_d_id),
@JoinColumn(name=ol_w_id, referencedColumnName=o_w_id)
})
Orders orders = null;
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns({
@JoinColumn(name=ol_i_id, referencedColumnName=s_i_id),
@JoinColumn(name=ol_supply_w_id, referencedColumnName=s_w_id)
})
Stock stock = null;
*
Now if I run the following client
UserTransaction ut = null;
ClientEJB facade = null;
EntityManager em = null;
try {
Hashtable parms = new Hashtable();
parms.put( Context.INITIAL_CONTEXT_FACTORY,
com.ibm.websphere.naming.WsnInitialContextFactory);
InitialContext ctx = new InitialContext(parms);
ut = (UserTransaction) ctx.lookup(java:comp/UserTransaction);
ut.begin();
em = getFactory().createEntityManager ();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] JOIN in subselect problems
roger.keays wrote:
Hi Marc,
Marc Prud wrote:
The query looks valid: it sounds like a pretty clear-cut bug. Can you
file a JIRA?
I've filed issue 173: https://issues.apache.org/jira/browse/OPENJPA-173
As for a workaround, is there an inverse from MailingList.subscribers
(e.g., Email.mailingList)? If so, then you might be able to re-cast
the query as:
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM Email m where m.mailingList IS NOT NULL)
Actually I found a similar solution to do what I need and the SQL it
produces is quite optimal:
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE ?1 MEMBER OF e.subscriptions OR ?2 MEMBER OF e.subscriptions
OR ...
Thanks again,
Roger
On Mar 13, 2007, at 2:04 AM, roger.keays wrote:
Is there anything wrong with the following query?
UPDATE Email e SET e.totalDeliveries = e.totalDeliveries + 1
WHERE e.email IN (
SELECT m.email FROM MailingList l JOIN l.subscribers m)
OpenJPA (0.9.6) parses this correctly, but can't seems to be
missing the
JOIN clause or some table names from the generated SQL:
org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: syntax
error at
or near WHERE {prepstmnt 27475707 UPDATE FB_EMAILS SET
totalDeliveries =
(totalDeliveries + ?) WHERE email IN (SELECT DISTINCT t2.email FROM
WHERE
(t2.email IN (SELECT t3.email FROM FB_EMAILS t3 WHERE t0.id = t1.id
AND
t1.subscribers_email = t3.email))) [params=(long) 1]} [code=0,
state=42601]
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap
(LoggingConnectionDecorator.java:188)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$800
(LoggingConnectionDecorator.java:53)
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator
$LoggingConnection$LoggingPreparedStatement.executeUpdate
(LoggingConnectionDecorator.java:854)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(
DelegatingPreparedStatement.java:266)
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(
DelegatingPreparedStatement.java:266)
org.apache.openjpa.jdbc.kernel.JDBCStoreManager
$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1360)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeBulkOperation
(JDBCStoreQuery.java:491)
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeUpdate
(JDBCStoreQuery.java:420)
org.apache.openjpa.kernel.ExpressionStoreQuery
$DataStoreExecutor.executeUpdate(ExpressionStoreQuery.java:685)
org.apache.openjpa.datacache.QueryCacheStoreQuery
$QueryCacheExecutor.executeUpdate(QueryCacheStoreQuery.java:343)
org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1028)
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:793)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:868)
org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:864)
org.apache.openjpa.kernel.DelegatingQuery.updateAll
(DelegatingQuery.java:560)
org.apache.openjpa.persistence.QueryImpl.executeUpdate
(QueryImpl.java:304)
Thanks,
Roger
--
View this message in context: http://www.nabble.com/JOIN-in-
subselect-problems-tf3394694.html#a9450588
Sent from the open-jpa-dev mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/JOIN-in-subselect-problems-tf3394694.html#a9467152
Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Another bad Maven day
Craig- Yes, there do appear to be problems. If I clobber my repository (so that the latest surefire plugin is downloaded) and try to run the tests, everything fails with java.lang.ClassNotFoundException: org.apache.openjpa.util.CacheMap. I'll try to look into it tonight... On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote: The surefire plugin was just updated from 2.2 to 2.3 and the instrumentation no longer works (for the cayenne project at least). Anyone know whether this affects us? Craig Begin forwarded message: From: Andrus Adamchik [EMAIL PROTECTED] Date: March 13, 2007 11:09:48 AM PDT To: dev@cayenne.apache.org Subject: Another bad Maven day Reply-To: dev@cayenne.apache.org Something changed in the Maven unit test class loading Instrumentation args no longer work... Somehow I think this is related to the new version of the surefire plugin that I noticed was loaded on March 7 :-( Andrus [INFO] Surefire report directory: /Users/andrus/work/cayenne/ itests/pojo/target/surefire-reports *** CayenneAgent starting... org.apache.maven.surefire.booter.SurefireExecutionException: org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is java.lang.ExceptionInInitializerError: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is java.lang.ExceptionInInitializerError: null org.apache.maven.surefire.testset.TestSetFailedException: org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is java.lang.ExceptionInInitializerError: null java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance (Constructor.java:494) at junit.framework.TestSuite.createTest(TestSuite.java:131) at junit.framework.TestSuite.addTestMethod(TestSuite.java: 114) at junit.framework.TestSuite.init(TestSuite.java:75) at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance (Constructor.java:494) at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject (JUnitTestSet.java:151) at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount (JUnitTestSet.java:247) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTest Sets(AbstractDirectoryTestSuite.java:104) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition (Surefire.java:150) at org.apache.maven.surefire.Surefire.run(Surefire.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess (SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.java:818) Caused by: java.lang.NullPointerException at org.apache.cayenne.itest.pojo.PojoTestCase.clinit (PojoTestCase.java:35) ... 22 more Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Another bad Maven day
Mike- Thanks for the tip. Adding useSystemClassLoader seems to fix the problem so I've gone ahead and added that to our pom.xml. On Mar 13, 2007, at 8:05 PM, Michael Dick wrote: I think we're running into a side effect of http://jira.codehaus.org/browse/SUREFIRE-301 (just a guess though). I was able to get the tests to run by going back to surefire 2.2, or setting useSystemClassLoader to true in the surefire configuration options. Either way should work. If we set the useSystemClassLoader config option we can pick up new versions of surefire in the mean time. Then again maybe we're better off with a version that we know works. -Mike On 3/13/07, Craig L Russell [EMAIL PROTECTED] wrote: The cayenne guys just hard coded their dependency on surefire to 2.2. I don't know if the maven surefire folks are aware of this issue. I personally don't know who to talk to over there... Craig On Mar 13, 2007, at 6:56 PM, Marc Prud'hommeaux wrote: Craig- Yes, there do appear to be problems. If I clobber my repository (so that the latest surefire plugin is downloaded) and try to run the tests, everything fails with java.lang.ClassNotFoundException: org.apache.openjpa.util.CacheMap. I'll try to look into it tonight... On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote: The surefire plugin was just updated from 2.2 to 2.3 and the instrumentation no longer works (for the cayenne project at least). Anyone know whether this affects us? Craig Begin forwarded message: From: Andrus Adamchik [EMAIL PROTECTED] Date: March 13, 2007 11:09:48 AM PDT To: dev@cayenne.apache.org Subject: Another bad Maven day Reply-To: dev@cayenne.apache.org Something changed in the Maven unit test class loading Instrumentation args no longer work... Somehow I think this is related to the new version of the surefire plugin that I noticed was loaded on March 7 :-( Andrus [INFO] Surefire report directory: /Users/andrus/work/cayenne/ itests/pojo/target/surefire-reports *** CayenneAgent starting... org.apache.maven.surefire.booter.SurefireExecutionException: org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is java.lang.ExceptionInInitializerError: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is java.lang.ExceptionInInitializerError: null org.apache.maven.surefire.testset.TestSetFailedException: org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is java.lang.ExceptionInInitializerError: null java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance (Constructor.java:494) at junit.framework.TestSuite.createTest(TestSuite.java: 131) at junit.framework.TestSuite.addTestMethod (TestSuite.java: 114) at junit.framework.TestSuite.init(TestSuite.java:75) at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance (Constructor.java:494) at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject (JUnitTestSet.java:151) at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount (JUnitTestSet.java:247) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTes tSets(AbstractDirectoryTestSuite.java:104) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition (Surefire.java:150) at org.apache.maven.surefire.Surefire.run (Surefire.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess (SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main (SurefireBooter.java:818) Caused by: java.lang.NullPointerException at org.apache.cayenne.itest.pojo.PojoTestCase.clinit (PojoTestCase.java:35) ... 22 more Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System
