RE: Google Summer Of Code
Thanks for the links. I skimmed through them and put together http://wiki.apache.org/general/SummerOfCode2007#openjpa-streaming-lobs. Could someone in the know take a look at that and let me know if it looks right? Also, the code.google.com docs mention that any communication from the student to the project before the project is approved is looked upon favorably. How do we go about highlighting Ignacio's initiative to the deciders at Google? Thanks, -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: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Sunday, March 25, 2007 12:40 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Google Summer Of Code On 3/25/07, Patrick Linskey [EMAIL PROTECTED] wrote: http://code.google.com/support/bin/answer.py?answer=60325topi c=10729 . Finally, if you agree about the time frame, I'm going to choose the OPENJPA-130 A few process questions: 1. What are our (the OpenJPA community and the Apache organization) commitments and responsibilities in this process? I don't see Apache listed as a mentoring organization at http://code.google.com/soc/2006/ (last year's program page), and I don't see an updated list for this year. Does Apache / OpenJPA need to be a mentoring organization, or is the mentoring organization decoupled from the codebase that is worked on? apache is a mentoring organization (http://code.google.com/soc/asf/about.html) but is listed as 'The Apache Software Foundation' not 'Apache'. more details about [EMAIL PROTECTED] can be found on http://wiki.apache.org/general/SummerOfCode2007. a mentor from openJPA will need to volunteer. anyone who's interested needs to read http://wiki.apache.org/general/SummerOfCodeMentor and the linked pages on google. - robert Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Google Summer Of Code
On 3/26/07, Patrick Linskey [EMAIL PROTECTED] wrote: Thanks for the links. I skimmed through them and put together http://wiki.apache.org/general/SummerOfCode2007#openjpa-streaming-lobs. Could someone in the know take a look at that and let me know if it looks right? looks ok to me but more eyeballs, the better Also, the code.google.com docs mention that any communication from the student to the project before the project is approved is looked upon favorably. How do we go about highlighting Ignacio's initiative to the deciders at Google? not sure (i've never been a mentor). community AT apache is probably a good place to ask. AIUI the deadline for students is today so time is short and Ignacio needs to apply very quickly - robert
[jira] Created: (OPENJPA-181) ClassCastException when executing bulk delete on an entity that owns a OneToOne with a Cascade.DELETE when DataCache is on
ClassCastException when executing bulk delete on an entity that owns a OneToOne
with a Cascade.DELETE when DataCache is on
--
Key: OPENJPA-181
URL: https://issues.apache.org/jira/browse/OPENJPA-181
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 0.9.7
Reporter: Jonathan Feinberg
Given an entity class A which owns a OneToOne entity of class B, and given a
cascade on that OneToOne that includes DELETE, an attempt to bulk-delete A when
using the DataCache results in a stack trace like the following:
java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery
cannot be cast to org.apache.openjpa.kernel.ExpressionStoreQuery
at
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:674)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:979)
at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1005)
... 28 more
The proximate cause for the bug is that when the JDBCStoreQuery does this:
private Table getTable(FieldMapping fm, Table table) {
if (fm.getCascadeDelete() != ValueMetaData.CASCADE_NONE)
return INVALID;
it causes isSingleTableMapping to be considered false, which in turn permits
executeBulkOperation to return null. Meanwhile, back in DataStoreExecutor:
public Number executeDelete(StoreQuery q, Object[] params) {
Number num = ((ExpressionStoreQuery) q).executeDelete(this, _meta,
_metas, _subs, _facts, _exps, params);
if (num == null)
return q.getContext().deleteInMemory(this, params); // - now
we have come here because executeDelete punted
return num;
}
So deleteInMemory gets called in QueryImpl:
public Number deleteInMemory(StoreQuery.Executor executor,
Object[] params) {
try {
Object o = execute(executor, params);
, but a DataStoreExecutor doesn't know how to execute the QueryCacheStoreQuery
that it gets.
Somehwere, something is too unwrapped, or not wrapped enough. Good luck!
Workaround:
If A owns B, then instead of cascade=CascadeType.ALL, you can
@Entity
class A {
B myThing;
@OneToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE,
CascadeType.REFRESH })
B getMyThing() { return myThing; }
}
@Entity
class B {
A owner;
@ForeignKey(deleteAction=ForeignKeyAction.CASCADE)
A getOwner() { return owner; }
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-181) ClassCastException when executing bulk delete on an entity that owns a OneToOne with a Cascade.DELETE when DataCache is on
[
https://issues.apache.org/jira/browse/OPENJPA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Feinberg updated OPENJPA-181:
--
Description:
Given an entity class A which owns a OneToOne entity of class B, and given a
cascade on that OneToOne that includes DELETE, an attempt to bulk-delete A when
using the DataCache results in a stack trace like the following:
{code}
java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery
cannot be cast to org.apache.openjpa.kernel.ExpressionStoreQuery
at
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:674)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:979)
at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1005)
... 28 more
{code}
The proximate cause for the bug is that when the JDBCStoreQuery does this:
private Table getTable(FieldMapping fm, Table table) {
if (fm.getCascadeDelete() != ValueMetaData.CASCADE_NONE)
return INVALID;
it causes isSingleTableMapping to be considered false, which in turn permits
executeBulkOperation to return null. Meanwhile, back in DataStoreExecutor:
public Number executeDelete(StoreQuery q, Object[] params) {
Number num = ((ExpressionStoreQuery) q).executeDelete(this, _meta,
_metas, _subs, _facts, _exps, params);
if (num == null)
return q.getContext().deleteInMemory(this, params); // - now
we have come here because executeDelete punted
return num;
}
So deleteInMemory gets called in QueryImpl:
public Number deleteInMemory(StoreQuery.Executor executor,
Object[] params) {
try {
Object o = execute(executor, params);
, but a DataStoreExecutor doesn't know how to execute the QueryCacheStoreQuery
that it gets.
Somehwere, something is too unwrapped, or not wrapped enough. Good luck!
Workaround:
If A owns B, then instead of cascade=CascadeType.ALL, you can
@Entity
class A {
B myThing;
@OneToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE,
CascadeType.REFRESH })
B getMyThing() { return myThing; }
}
@Entity
class B {
A owner;
@ForeignKey(deleteAction=ForeignKeyAction.CASCADE)
A getOwner() { return owner; }
}
was:
Given an entity class A which owns a OneToOne entity of class B, and given a
cascade on that OneToOne that includes DELETE, an attempt to bulk-delete A when
using the DataCache results in a stack trace like the following:
java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery
cannot be cast to org.apache.openjpa.kernel.ExpressionStoreQuery
at
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:674)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:979)
at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1005)
... 28 more
The proximate cause for the bug is that when the JDBCStoreQuery does this:
private Table getTable(FieldMapping fm, Table table) {
if (fm.getCascadeDelete() != ValueMetaData.CASCADE_NONE)
return INVALID;
it causes isSingleTableMapping to be considered false, which in turn permits
executeBulkOperation to return null. Meanwhile, back in DataStoreExecutor:
public Number executeDelete(StoreQuery q, Object[] params) {
Number num = ((ExpressionStoreQuery) q).executeDelete(this, _meta,
_metas, _subs, _facts, _exps, params);
if (num == null)
return q.getContext().deleteInMemory(this, params); // - now
we have come here because executeDelete punted
return num;
}
So deleteInMemory gets called in QueryImpl:
public Number deleteInMemory(StoreQuery.Executor executor,
Object[] params) {
try {
Object o = execute(executor, params);
, but a DataStoreExecutor doesn't know how to execute the QueryCacheStoreQuery
that it gets.
Somehwere, something is too unwrapped, or not wrapped enough. Good luck!
Workaround:
If A owns B, then instead of cascade=CascadeType.ALL, you can
@Entity
class A {
B myThing;
@OneToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE,
CascadeType.REFRESH })
B getMyThing() { return myThing; }
}
@Entity
class B {
A owner;
@ForeignKey(deleteAction=ForeignKeyAction.CASCADE)
A getOwner() { return owner; }
}
ClassCastException when executing bulk delete on an entity that owns a
OneToOne with a Cascade.DELETE when DataCache is on
--
Key: OPENJPA-181
URL: https://issues.apache.org/jira/browse/OPENJPA-181
Project: OpenJPA
Issue Type: Bug
[jira] Created: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
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 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.
0.9.7 release
Hi guys, We've started preparing an incubator release for ODE and we're now using OpenJPA (pretty happily I should say). We can't use 0.9.6 as we need a couple of fixes from 0.9.7 so we've been using the snapshot so far. But as you know we won't be able to release with it (and generally speaking depending on snapshots is not that nice). So we were just wondering if you had any time frame so far for 0.9.7 final. I've seen that you started discussing future plans so maybe 0.9.7 should happen soon enough? Thanks, Matthieu
[jira] Commented: (OPENJPA-172) DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.
[
https://issues.apache.org/jira/browse/OPENJPA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484226
]
Kevin Sutter commented on OPENJPA-172:
--
Ritika,
The message you referenced...
0|true|0.9.6-incubating org.apache.openjpa.persistence.PersistenceException:
DSRA9250E: Operation setTransactionIsolation is not allowed during a global
transaction for Shareable Connections.
... is coming from WebSphere. WebSphere supports the concept of shareable
connections (per the JCA specification). Since these connections might be
shared between applications, WebSphere doesn't want to surprise the user of a
Shareable connection by allowing modification of properties that could affect
the operation of that connection. In this case, somebody (OpenJPA?) is
attempting to change the TransactionIsolation attribute of a Shareable
connection while a global transaction is active. WebSphere prevents this as a
safety net for our users. So, it looks like you need to understand why the
transaction isolation is attempted to be set while the transaction is active.
Either we need to hold off on changing the transaction isolation until the tran
completes, or maybe the setting is superfluous (ie. the isolation level is not
changing, but the invocation is happening regardless).
Hope this helps.
Kevin
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.7
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;
Re: Shared classloader and subclasses
I've committed an equivalent patch to 0.9.7 in SVN revision 522623.
Can you confirm whether this fixes your problem and, if so, close any
CR you might have opened on this?
This works for me :) Here's a patch for 0.9.6 source. I've gone for
the
simplest solution, but it might be improved by looping over pcNames
instead
of _registered (?).
http://www.nabble.com/file/7398/openjpa-diff openjpa-diff
Index: MetaDataRepository.java
===
--- MetaDataRepository.java
(.../tags/0.9.6/openjpa-kernel/src/main/java/org/apache/openjpa/meta)
(revision 3)
+++ MetaDataRepository.java
(.../branches/0.9.6-ninthavenue/openjpa-kernel/src/main/java/org/
apache/openjpa/meta)
(working copy)
@@ -302,7 +302,7 @@
return null;
// check cache
-processRegisteredClasses();
+processRegisteredClasses(envLoader);
List classList = (List) _aliases.get(alias);
// multiple classes may have been defined with the same
alias: we
@@ -928,7 +928,7 @@
}
// check cache
-processRegisteredClasses();
+processRegisteredClasses(envLoader);
Class cls = (Class) _oids.get(oid.getClass());
if (cls != null)
return getMetaData(cls, envLoader, mustExist);
@@ -944,7 +944,7 @@
// if still not match, register any classes that look
similar to
the
// oid class and check again
resolveIdentityClass(oid);
-if (processRegisteredClasses().length 0) {
+if (processRegisteredClasses(envLoader).length 0) {
cls = (Class) _oids.get(oid.getClass());
if (cls != null)
return getMetaData(cls, envLoader, mustExist);
@@ -1262,7 +1262,7 @@
* Parses the metadata for all registered classes.
*/
private void loadRegisteredClassMetaData(ClassLoader envLoader) {
-Class[] reg = processRegisteredClasses();
+Class[] reg = processRegisteredClasses(envLoader);
for (int i = 0; i reg.length; i++) {
try {
getMetaData(reg[i], envLoader, false);
@@ -1276,7 +1276,7 @@
/**
* Updates our datastructures with the latest registered classes.
*/
-Class[] processRegisteredClasses() {
+Class[] processRegisteredClasses(ClassLoader envLoader) {
if (_registered.isEmpty())
return EMPTY_CLASSES;
@@ -1289,9 +1289,18 @@
}
Collection failed = null;
+Collection pcNames = getPersistentTypeNames(false,
envLoader);
for (int i = 0; i reg.length; i++) {
try {
-processRegisteredClass(reg[i]);
+
+/*
+ * Only process classes known to this
MetaDataRepository,
+ * since _registered contains all classes loaded by
+ * PCRegistry.
+ */
+if (pcNames.contains(reg[i].getName())) {
+processRegisteredClass(reg[i]);
+}
} catch (Throwable t) {
if (!_conf.getRetryClassRegistration())
throw new
MetaDataException(_loc.get(error-registered,
Index: ClassMetaData.java
===
--- ClassMetaData.java
(.../tags/0.9.6/openjpa-kernel/src/main/java/org/apache/openjpa/meta)
(revision 4)
+++ ClassMetaData.java
(.../branches/0.9.6-ninthavenue/openjpa-kernel/src/main/java/org/
apache/openjpa/meta)
(working copy)
@@ -309,7 +309,7 @@
if (_owner != null)
return _repos.EMPTY_CLASSES;
-_repos.processRegisteredClasses();
+_repos.processRegisteredClasses(getEnvClassLoader());
if (_subs == null) {
Collection subs = _repos.getPCSubclasses(_type);
_subs = (Class[]) subs.toArray(new Class[subs.size()]);
--
View this message in context: http://www.nabble.com/Shared-
classloader-and-subclasses-tf3431312.html#a9655900
Sent from the open-jpa-dev mailing list archive at Nabble.com.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: OPEN-JPA and Toplink 2.0.XX
Well, you still need the implementation of the persistence api jar in your classpath. You can download the api jar by itself (without the toplink stuff) from https://maven-repository.dev.java.net/nonav/repository/ javax.persistence/jars/persistence-api-1.0.jar Craig On Mar 26, 2007, at 2:24 PM, Phill Moran wrote: Odd response to the removal of the toplink jar. The same code with only this change no longer runs the tests. Complains about can't find entity manager. I am starting my investigations but thought I would throw this in the loop to see if someone has seen this before Phill -Original Message- From: Phill Moran [mailto:[EMAIL PROTECTED] Sent: March 25, 2007 10:24 PM To: 'open-jpa-dev@incubator.apache.org' Subject: RE: OPEN-JPA and Toplink 2.0.XX This is exactly what happened and I added my own implementation when I tried to test and got nothing. Well bye bye toplink -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: March 25, 2007 10:04 PM To: open-jpa-dev@incubator.apache.org Subject: Re: OPEN-JPA and Toplink 2.0.XX On Mar 25, 2007, at 3:24 PM, Phill Moran wrote: This is interesting thanks for the information. Firstly I thought that one needed both toplink and JPA to make use of JPA in an application. I think I found this on the Glassfish site, can't remember now. This is why I posted this here. Glassfish distributes TopLink Essentials bundled with the JPA spec jar, so you might have unwittingly acquired TopLink Essentials along with the spec jar and not unsurprisingly, figured that they were the same. Since that experiment at the beginning of the official RI distribution of Java EE 5, the JPA spec jar has been unbundled and is available separately from TopLink Essentials. You are free to use any implementation of the spec that you choose. Craig Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo 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! smime.p7s Description: S/MIME cryptographic signature
RE: OPEN-JPA and Toplink 2.0.XX
No I have providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider I don't have the API jar as I figured it is only empty stubs and of no value with OpenJPA-all jar Here is my Maven dependency section dependency groupIdaspectj/groupId artifactIdaspectjrt/artifactId version1.5.3/version /dependency dependency groupIdaspectj/groupId artifactIdaspectjweaver/artifactId version1.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.0.4/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring/artifactId version2.0.3/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-agent/artifactId version2.0.3/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-aspects/artifactId version2.0.3/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-mock/artifactId version2.0.3/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.2/version /dependency dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId version1.1/version /dependency dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.6-incubating/version /dependency dependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /dependency dependency groupIdjavax.j2ee/groupId artifactIdjavaee/artifactId version1.5/version /dependency dependency groupIdcom.sun/groupId artifactIdtools/artifactId version1.6/version /dependency /dependencies -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: March 26, 2007 5:27 PM To: open-jpa-dev@incubator.apache.org Subject: RE: OPEN-JPA and Toplink 2.0.XX Do you maybe have providerpath.to.ToplinkPersistenceProviderImpl/provider in your persistence.xml? If so, what happens if you remove it / change it to point to org.apache.openjpa.persistence.PersistenceProviderImpl? -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: Phill Moran [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 2:25 PM To: 'Phill Moran'; open-jpa-dev@incubator.apache.org Subject: RE: OPEN-JPA and Toplink 2.0.XX Odd response to the removal of the toplink jar. The same code with only this change no longer runs the tests. Complains about can't find entity manager. I am starting my investigations but thought I would throw this in the loop to see if someone has seen this before Phill -Original Message- From: Phill Moran [mailto:[EMAIL PROTECTED] Sent: March 25, 2007 10:24 PM To: 'open-jpa-dev@incubator.apache.org' Subject: RE: OPEN-JPA and Toplink 2.0.XX This is exactly what happened and I added my own implementation when I tried to test and got nothing. Well bye bye toplink -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: March 25, 2007 10:04 PM To: open-jpa-dev@incubator.apache.org Subject: Re: OPEN-JPA and Toplink 2.0.XX On Mar 25, 2007, at 3:24 PM, Phill Moran wrote:
ID class: no public string or class + string constructor?
getting this error: The id type class com.sun.portal.pom.FooId specfied by persistent type class com.sun.portal.pom.Foo does not have a public string or class + string constructor. this error doesn't seem to correspond to any of the requirements of an ID class as defined in the spec. my first guess is that it wants me to add an constructor that takes the result of toString() and constructs the ID class based on that, but adding a constructor that takes a string arg didn't change the error. i don't understand what it would want for the class + string constructor, so i was not sure what to try there. can someone help interpret this error? thanks! - Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.
Re: ID class: no public string or class + string constructor?
Hi Jeff, It would be useful if you could include a code fragment and the @Id annotation for your class to diagnose this. Thanks, Craig On Mar 26, 2007, at 4:35 PM, jeff wrote: getting this error: The id type class com.sun.portal.pom.FooId specfied by persistent type class com.sun.portal.pom.Foo does not have a public string or class + string constructor. this error doesn't seem to correspond to any of the requirements of an ID class as defined in the spec. my first guess is that it wants me to add an constructor that takes the result of toString() and constructs the ID class based on that, but adding a constructor that takes a string arg didn't change the error. i don't understand what it would want for the class + string constructor, so i was not sure what to try there. can someone help interpret this error? thanks! - Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OPENJPA-172) DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.
[
https://issues.apache.org/jira/browse/OPENJPA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484280
]
Kevin Sutter commented on OPENJPA-172:
--
It sounds like WebSphere is working as expected. Since you are attempting to
modify a Connection while a transaction is active, WebSphere is preventing the
action. As you outlined, this would happen with setTransactionIsolation,
setAutoCommit, and a few other settings that would compromise a shared
connection.
You could run with an Unshareable connection, but that's easier said than done
since Shareable connections are the default when accessing via direct JNDI
lookups.
Another idea is to delay the starting of the transaction, but that may be
application-specific. That is, you might be able to work around this situation
in your given application, but that doesn't sound like a general purpose
solution.
What we might have to do is to use a JDBCConnectionSpec when attempting to get
a Connection via the WSDataSource interface. This is very WebSphere specific,
but I'm not sure what else we can do.
I'm surprised that we haven't hit this type of problem with other application
servers. Either the JNDI lookup is returning an Unshareable connection, or
setting the isolation level on Shareable connections is allowed. Neither of
these options is consistent with the expected behavior. Can anyone comment?
I'm trying to figure out if we have a WebSphere-specific situation or a more
genera problem.
Kevin
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.7
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),
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484288 ] Patrick Linskey commented on OPENJPA-168: - 2. I don't think we need a FetchConfiguration instance variable. My understanding is that you can often provide hints about how many results might be returned, as well as whether one or many results will be loaded. So it seems like we might want to expose some way for the user to specify for an arbitrary query (or relation load) that they expect n records to be returned. 4. getOptimizeClause seems too generic. Agreed. The optimizations tend to get tucked into different parts of the SQL statement; this probably will end up needing to be significantly different for different db back-ends. 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] Created: (OPENJPA-183) OpenJPAEntityManager large transaction APIs should take class arguments to narrow behavior
OpenJPAEntityManager large transaction APIs should take class arguments to narrow behavior -- Key: OPENJPA-183 URL: https://issues.apache.org/jira/browse/OPENJPA-183 Project: OpenJPA Issue Type: Improvement Components: datacache Reporter: Patrick Linskey OpenJPAEntityManager.setLargeTransaction() and OpenJPAEntityManager.setPopulateDataCache() control how a given transaction uses the data cache. These APIs (and in particular, setLargeTransaction()) would benefit from being per-class (or per-class-hierarchy) instead of being global to all classes in a transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: ID class: no public string or class + string constructor?
Sounds like an over-cautious validation message originating in OpenJPA's heritage -- the JDO spec (which Kodo implements on top of OpenJPA) places those requirements on the object IDs. If you could post the full stack trace and the relevant snippets from your domain model, it'd help the debugging process considerably. Thanks, -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: jeff [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 4:35 PM To: open-jpa-dev@incubator.apache.org Subject: ID class: no public string or class + string constructor? getting this error: The id type class com.sun.portal.pom.FooId specfied by persistent type class com.sun.portal.pom.Foo does not have a public string or class + string constructor. this error doesn't seem to correspond to any of the requirements of an ID class as defined in the spec. my first guess is that it wants me to add an constructor that takes the result of toString() and constructs the ID class based on that, but adding a constructor that takes a string arg didn't change the error. i don't understand what it would want for the class + string constructor, so i was not sure what to try there. can someone help interpret this error? thanks! - Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. 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.
