Vlad Tatavu is out of the office.
I will be out of the office starting 12/02/2007 and will not return until 16/02/2007. I will respond to your message when I return.
RE: MappingTool does not create "not null" column for @ManyToOne(optional=false)
I don't have the OpenJPA code, so I cannot look at it.
You are right, OpenJPA will enforce the constraint in Java, but I expect
the MappingTool to apply the NOT NULL to the database for the attribute
that is annotated with @ManyToOne - not to the "remote" attribute.
Example:
@Entity
public class TestAssociation {
@Id
@GeneratedValue
public int id;
@ManyToOne(optional=false)
@ForeignKey
TestEntity assoced;
}
The MappingTool executes the following commands for this class:
CREATE TABLE TestAssociation (id INTEGER NOT NULL, assoced_id INTEGER,
PRIMARY KEY (id))
ALTER TABLE TestAssociation ADD FOREIGN KEY (assoced_id) REFERENCES
TestEntity (id)
I expect the TestAssociation.assoced_id to be NOT NULL, not TestEntity.id.
TestEntity.id is NOT NULL already because it is primary key.
Vlad
"Patrick Linskey" <[EMAIL PROTECTED]>
12/01/2007 04:00 PM
Please respond to
open-jpa-dev@incubator.apache.org
To
cc
Subject
RE: MappingTool does not create "not null" column for
@ManyToOne(optional=false)
See AnnotationPersistenceMetaDataParser.java:1201: if optional is false,
then OpenJPA (not the database) will throw an exception if a null is
specified. This is not propagated to foreign key constraints; those
should be configured via the @ForeignKey annotation, by setting the
updateAction appropriately.
-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: Vlad Tatavu [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 12, 2007 12:44 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: MappingTool does not create "not null" column for
> @ManyToOne(optional=false)
>
> If I use @ManyToOne(optional=false) to annotate an attribute, the
> MappingTool does not create a NOT NULL column in the
> corresponding table.
> Bug?
>
> Vlad
>
MappingTool does not create "not null" column for @ManyToOne(optional=false)
If I use @ManyToOne(optional=false) to annotate an attribute, the MappingTool does not create a NOT NULL column in the corresponding table. Bug? Vlad
Re: @ForeignKey not allowed for @ManyToMany
I wouldn't say that's obvious, but it make sense and it works. Thanks! Vlad Abe White <[EMAIL PROTECTED]> 12/01/2007 03:24 PM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: @ForeignKey not allowed for @ManyToMany > Is there a reason why @ForeignKey is not allowed for @ManyToMany? Because the field value is a collection, not a reference. You want to use @ElementForeignKey. ___ 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.
@ForeignKey not allowed for @ManyToMany
Is there a reason why @ForeignKey is not allowed for @ManyToMany? Vlad
[jira] Commented: (OPENJPA-98) Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0
[ https://issues.apache.org/jira/browse/OPENJPA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463391 ] Vlad Tatavu commented on OPENJPA-98: I cannot reproduce this problem with Sun JDK 1.5.0_04. > Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0 > --- > > Key: OPENJPA-98 > URL: https://issues.apache.org/jira/browse/OPENJPA-98 > Project: OpenJPA > Issue Type: Bug > Environment: OpenJPA: > 0.9.6 > Java: > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20061002a > (SR3) > ) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 > j9vmwi3223-2006100 > 1 (JIT enabled) > J9VM - 20060915_08260_lHdSMR > JIT - 20060908_1811_r8 > GC - 20060906_AA) > JCL - 20061002 > DB: > Derby 10.2.1.6 >Reporter: Vlad Tatavu > Attachments: console.txt, javacore.20070109.114312.3868.zip, play.zip > > > I have a simple test program that uses OpenJPA 0.9.6 to insert an object into > a db in one transaction (t1) and retrieve it in another transaction (t2). > The program hangs in 30-50% of the executions right before the call to > entitymanager.find() (used to retrieve the object in t2). I'm using OpenJPA > runtime enhancement. > By looking at the JVM dump, I can see the following deadlock: > 1LKDEADLOCKDeadlock detected !!! > NULL - > NULL > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > 3LKDEADLOCKWTRis waiting for: > 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: > 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) > 3LKDEADLOCKWTRwhich is waiting for: > 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: > 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-98) Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0
[ https://issues.apache.org/jira/browse/OPENJPA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463388 ] Vlad Tatavu commented on OPENJPA-98: Attachments: play.zip - the Eclipse project used to reproduce this problem javacore.20070109.114312.3868.zip - java dump after the deadlock occured console.txt - java console of the test program after the deadlock occured > Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0 > --- > > Key: OPENJPA-98 > URL: https://issues.apache.org/jira/browse/OPENJPA-98 > Project: OpenJPA > Issue Type: Bug > Environment: OpenJPA: > 0.9.6 > Java: > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20061002a > (SR3) > ) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 > j9vmwi3223-2006100 > 1 (JIT enabled) > J9VM - 20060915_08260_lHdSMR > JIT - 20060908_1811_r8 > GC - 20060906_AA) > JCL - 20061002 > DB: > Derby 10.2.1.6 >Reporter: Vlad Tatavu > Attachments: console.txt, javacore.20070109.114312.3868.zip, play.zip > > > I have a simple test program that uses OpenJPA 0.9.6 to insert an object into > a db in one transaction (t1) and retrieve it in another transaction (t2). > The program hangs in 30-50% of the executions right before the call to > entitymanager.find() (used to retrieve the object in t2). I'm using OpenJPA > runtime enhancement. > By looking at the JVM dump, I can see the following deadlock: > 1LKDEADLOCKDeadlock detected !!! > NULL - > NULL > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > 3LKDEADLOCKWTRis waiting for: > 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: > 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) > 3LKDEADLOCKWTRwhich is waiting for: > 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: > 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-98) Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0
[ https://issues.apache.org/jira/browse/OPENJPA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlad Tatavu updated OPENJPA-98: --- Attachment: console.txt javacore.20070109.114312.3868.zip play.zip > Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0 > --- > > Key: OPENJPA-98 > URL: https://issues.apache.org/jira/browse/OPENJPA-98 > Project: OpenJPA > Issue Type: Bug > Environment: OpenJPA: > 0.9.6 > Java: > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20061002a > (SR3) > ) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 > j9vmwi3223-2006100 > 1 (JIT enabled) > J9VM - 20060915_08260_lHdSMR > JIT - 20060908_1811_r8 > GC - 20060906_AA) > JCL - 20061002 > DB: > Derby 10.2.1.6 >Reporter: Vlad Tatavu > Attachments: console.txt, javacore.20070109.114312.3868.zip, play.zip > > > I have a simple test program that uses OpenJPA 0.9.6 to insert an object into > a db in one transaction (t1) and retrieve it in another transaction (t2). > The program hangs in 30-50% of the executions right before the call to > entitymanager.find() (used to retrieve the object in t2). I'm using OpenJPA > runtime enhancement. > By looking at the JVM dump, I can see the following deadlock: > 1LKDEADLOCKDeadlock detected !!! > NULL - > NULL > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > 3LKDEADLOCKWTRis waiting for: > 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: > 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) > 3LKDEADLOCKWTRwhich is waiting for: > 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: > 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OPENJPA-98) Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0
Java deadlock when insert in t1 and find in t2 when using IBM JVM 1.5.0 --- Key: OPENJPA-98 URL: https://issues.apache.org/jira/browse/OPENJPA-98 Project: OpenJPA Issue Type: Bug Environment: OpenJPA: 0.9.6 Java: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20061002a (SR3) ) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006100 1 (JIT enabled) J9VM - 20060915_08260_lHdSMR JIT - 20060908_1811_r8 GC - 20060906_AA) JCL - 20061002 DB: Derby 10.2.1.6 Reporter: Vlad Tatavu I have a simple test program that uses OpenJPA 0.9.6 to insert an object into a db in one transaction (t1) and retrieve it in another transaction (t2). The program hangs in 30-50% of the executions right before the call to entitymanager.find() (used to retrieve the object in t2). I'm using OpenJPA runtime enhancement. By looking at the JVM dump, I can see the following deadlock: 1LKDEADLOCKDeadlock detected !!! NULL - NULL 2LKDEADLOCKTHR Thread "main" (0x0015EC00) 3LKDEADLOCKWTRis waiting for: 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: 3LKDEADLOCKOWNwhich is owned by: 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) 3LKDEADLOCKWTRwhich is waiting for: 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: 3LKDEADLOCKOWNwhich is owned by: 2LKDEADLOCKTHR Thread "main" (0x0015EC00) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes first persistence unit defined in persistence.xml
I know. I just said that because it is somehow related... -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853 "Kevin Sutter" <[EMAIL PROTECTED]> 09/01/2007 12:20 PM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes first persistence unit defined in persistence.xml Vlad, I'm currently not specifying a persistence file on the javaagent parameter. I only specify where to find the class files for kicking off the runtime enhancement: -javaagent:C:/eclipse.workspaces/3.2rc2/openjpa/openjpa-all/target/openjpa- all-0.9.7-incubating-SNAPSHOT.jar I let the runtime find my persistence.xml file in my META-INF directory. Kevin On 1/9/07, Vlad Tatavu <[EMAIL PROTECTED]> wrote: > > Being able to specify multiple persistence files as args for the javaagent > would be VERY useful as well. Currently, only one file name can be passed > as arg to the javaagent. > -- > Best regards, > Vlad Tatavu > Provisioning & Orchestration Development, IBM Tivoli Toronto > [EMAIL PROTECTED] > Office (905) 413-3853 > > > > Igor Fedorenko <[EMAIL PROTECTED]> > 09/01/2007 11:56 AM > Please respond to > open-jpa-dev@incubator.apache.org > > > To > open-jpa-dev@incubator.apache.org > cc > > Subject > Re: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes first > persistence unit defined in persistence.xml > > > > > > > Does this bugreport cover persistent units defined in different > persistence.xml files too? If I am not mistaken, OpenJPA looks at first > persistent unit of randomly chosen persistence.xml file. > > - Original Message > From: Kevin Sutter (JIRA) <[EMAIL PROTECTED]> > To: open-jpa-dev@incubator.apache.org > Sent: Tuesday, January 9, 2007 11:41:27 AM > Subject: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes > first persistence unit defined in persistence.xml > > Runtime Enhancement only processes first persistence unit defined in > persistence.xml > > > > Key: OPENJPA-96 > URL: https://issues.apache.org/jira/browse/OPENJPA-96 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Reporter: Kevin Sutter > > > (This Issue may be related to OPENJPA-9, but since that one was specific > to static PCEnhancing, I thought I would open a separate Issue. Just in > case the solutions are separate.) > > I'm using dynamic runtime enhancement via the -javaagent parameter. It > seems that only the first persistence-unit defined in the persistence.xml > is being processed for the runtime enhancement. If the persistence.xml > has only one entry, no problem. But, if it has more than one entry, then > only the first persistence-unit definition is being processed for the > dynamic enhancement. > > When I turn trace on, I get the following message when the runtime > enhancement works: > > 8312 my persistence unit INFO [main] openjpa.MetaData - Found 1 > classes with metadata in 0 milliseconds. > 8943 my persistence unit TRACE [main] openjpa.Enhance - > "com/ibm/ws/persistence/tests/simple/TestEntity" requires runtime > enhancement: true > 9043 my persistence unit TRACE [main] openjpa.MetaData - Loading > metadata for "class com.ibm.ws.persistence.tests.simple.TestEntity" under > mode "[META][QUERY]". > > When this p-u definition is not first in my persistence.xml, the "8943" > message is missing and my test fails: > > 8512 my persistence unit INFO [main] openjpa.MetaData - Found 1 > classes with metadata in 0 milliseconds. > 8522 my persistence unit TRACE [main] openjpa.MetaData - Using metadata > factory > "[EMAIL PROTECTED]". > 8522 my persistence unit TRACE [main] openjpa.MetaData - Loading > metadata for "class com.ibm.ws.persistence.tests.simple.TestEntity" under > mode "[META][QUERY]". > > I eventually get the following message when running the testcase: > > <4|false|0.0.0> org.apache.openjpa.persistence.ArgumentException: Attempt > to cast instance "[EMAIL PROTECTED]" > to PersistenceCapable failed. Ensure that it has been enhanced. > FailedObject: [EMAIL PROTECTED] > at > org.apache.openjpa.kernel.BrokerImpl.assertPersistenceCapable( > BrokerImpl.java:4234) > at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2344) >
Re: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes first persistence unit defined in persistence.xml
Being able to specify multiple persistence files as args for the javaagent would be VERY useful as well. Currently, only one file name can be passed as arg to the javaagent. -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853 Igor Fedorenko <[EMAIL PROTECTED]> 09/01/2007 11:56 AM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes first persistence unit defined in persistence.xml Does this bugreport cover persistent units defined in different persistence.xml files too? If I am not mistaken, OpenJPA looks at first persistent unit of randomly chosen persistence.xml file. - Original Message From: Kevin Sutter (JIRA) <[EMAIL PROTECTED]> To: open-jpa-dev@incubator.apache.org Sent: Tuesday, January 9, 2007 11:41:27 AM Subject: [jira] Created: (OPENJPA-96) Runtime Enhancement only processes first persistence unit defined in persistence.xml Runtime Enhancement only processes first persistence unit defined in persistence.xml Key: OPENJPA-96 URL: https://issues.apache.org/jira/browse/OPENJPA-96 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Kevin Sutter (This Issue may be related to OPENJPA-9, but since that one was specific to static PCEnhancing, I thought I would open a separate Issue. Just in case the solutions are separate.) I'm using dynamic runtime enhancement via the -javaagent parameter. It seems that only the first persistence-unit defined in the persistence.xml is being processed for the runtime enhancement. If the persistence.xml has only one entry, no problem. But, if it has more than one entry, then only the first persistence-unit definition is being processed for the dynamic enhancement. When I turn trace on, I get the following message when the runtime enhancement works: 8312 my persistence unit INFO [main] openjpa.MetaData - Found 1 classes with metadata in 0 milliseconds. 8943 my persistence unit TRACE [main] openjpa.Enhance - "com/ibm/ws/persistence/tests/simple/TestEntity" requires runtime enhancement: true 9043 my persistence unit TRACE [main] openjpa.MetaData - Loading metadata for "class com.ibm.ws.persistence.tests.simple.TestEntity" under mode "[META][QUERY]". When this p-u definition is not first in my persistence.xml, the "8943" message is missing and my test fails: 8512 my persistence unit INFO [main] openjpa.MetaData - Found 1 classes with metadata in 0 milliseconds. 8522 my persistence unit TRACE [main] openjpa.MetaData - Using metadata factory "[EMAIL PROTECTED]". 8522 my persistence unit TRACE [main] openjpa.MetaData - Loading metadata for "class com.ibm.ws.persistence.tests.simple.TestEntity" under mode "[META][QUERY]". I eventually get the following message when running the testcase: <4|false|0.0.0> org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance "[EMAIL PROTECTED]" to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: [EMAIL PROTECTED] at org.apache.openjpa.kernel.BrokerImpl.assertPersistenceCapable(BrokerImpl.java:4234) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2344) at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2204) at org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:991) at org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:525) at com.ibm.ws.persistence.tests.simple.TestInsertAndFind.test001(TestInsertAndFind.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42
Re: Deadlock when insert in t1 and find in t2
Kevin, I use the MappingTool to create the db before I run the test program, so I don't have to specify any classes (i.e. ) in my persistence.xml - we don't really want to have to specify classes in persistence.xml because in the real project there are a lot of classes that use OpenJPA and the development cycle is obviously much shorter if developers don't have to worry about keeping the list of classes in synch. Since my code doesn't hang in 100% of the executions, it's obvious that it's about a race condition - so it may be difficult to reproduce on other machines. Based on what I know about OpenJPA, specifying the element(s) in persistence.xml will cause the enhancer to "touch" only the specified classes, so I think it's expected that this problem will be much more difficult (if not impossible) to reproduce in this case. I use exactly the same Derby and Java versions. I changed the openjpa.Log as you suggested and I still get the deadlock (as expected). The extra info in the log doesn't mean much to me, unfortunately. The stack traces in the java dump look much more interesting, but I don't know enough about OpenJPA to be able to draw any conclusions. I'll zip up my test Eclipse project and the Java dump and send them directly to you - if you don't mind. It looks like the mailing list server removes all attachments. -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853 "Kevin Sutter" <[EMAIL PROTECTED]> 09/01/2007 11:01 AM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: Deadlock when insert in t1 and find in t2 Vlad, Using your provided class, testcase, and persistence.xml (I'll try to append them and see if it works), I can not reproduce your problem. I have discovered several other anomolies, but not the one you are describing. One item that I did have to modify is to specify the specific entry in your persistence.xml. Without this, the automatic SchemaMapping doesn't kick in. But, after doing that, whether I use runtime enhancement or static enhancement, I can not reproduce the problem. I am using the following Derby version... databaseProductName: Apache Derby databaseProductVersion: 10.2.1.6 - (452058) driverName: Apache Derby Embedded JDBC Driver driverVersion: 10.2.1.6 - (452058) And, my Java version is as follows... C:\temp\play>java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20061002a (SR3)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20061001 (JIT enabled) J9VM - 20060915_08260_lHdSMR JIT - 20060908_1811_r8 GC - 20060906_AA) JCL - 20061002 You might want to change your trace level so as to get more help with the problem... Let us know what you find out. Thanks, Kevin On 1/8/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Vlad- Interesting ... looks like it has something to do with an interaction between the JVM and the PCClassFileTransformer agent (responsible for enhancing the entity classes at runtime). If you manually enhance your entities and then run without the -javaagent flag, do you ever get the deadlock? On Jan 8, 2007, at 12:25 PM, Vlad Tatavu wrote: > Yeah, it looks like the attachments were removed by the list > server. I'm > using Derby. Here are the stack traces for the two threads > involved in > the deadlock: > > 3XMTHREADINFO "main" (TID:0x0015EC00, sys_thread_t:0x00358470, > state:B, native ID:0x17B4) prio=5 > 4XESTACKTRACE at > com/ibm/oti/vm/BootstrapClassLoader.loadClass > (BootstrapClassLoader.java:63(Compiled > Code)) > 4XESTACKTRACE at > java/lang/ClassLoader.loadClass(ClassLoader.java:587(Compiled Code)) > 4XESTACKTRACE at > java/lang/ClassLoader.loadClass(ClassLoader.java:587(Compiled Code)) > 4XESTACKTRACE at > sun/misc/Launcher$AppClassLoader.loadClass(Launcher.java:327(Compiled > Code)) > 4XESTACKTRACE at > java/lang/ClassLoader.loadClass(ClassLoader.java:563(Compiled Code)) > 4XESTACKTRACE at java/lang/ClassLoader.defineClassImpl(Native > Method) > 4XESTACKTRACE at > java/lang/ClassLoader.defineClass(ClassLoader.java:223(Compiled Code)) > 4XESTACKTRACE at > java/security/SecureClassLoader.defineClass(SecureClassLoader.java : > 148(Compiled > Code)) > 4XESTACKTRACE at > java/net/URLClassLoader.defineClass(URLClassLoader.java:556(Compiled > Code)) > 4XESTACKTRACE at > java/net/URLClassLoader.access$400( URLClassLoader.java:119(Compiled > Code)) > 4XESTACKTRACE at > java/net/URLClassLoader$ClassFinder.run(URLC
Re: Deadlock when insert in t1 and find in t2
The IBM JVM 5 has "J9" in its name - I couldn't find one that doesn't have it. I tried the same code with Sun's JVM 1.5 (Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)) and I don't get the deadlock. Unfortunately, this doesn't help me because I have to use IBM JVM. -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853 "Kevin Sutter" <[EMAIL PROTECTED]> 08/01/2007 02:01 PM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: Deadlock when insert in t1 and find in t2 Hi Vlad, Can you provide a bit more information? Are you running in a managed environment or a standalone environment? Are these JTA transactions or Local transactions? What does your test program look like? What about the Entities? Maybe you can attach them to your next reply? I see that you are using the J9 JVM. I haven't tried that yet. I've been using the "standard" IBM JVM 1.5 at SR3 (or above). I doubt that this would make a different, but it might be useful to try this JVM as a test. What you are describing is basic JPA functionality, so there must be something unique with your application or environment. Thanks, Kevin On 1/8/07, Vlad Tatavu <[EMAIL PROTECTED]> wrote: > > I have a simple test program that uses OpenJPA 0.9.6 to insert an object > into a db in one transaction (t1) and retrieve it in another transaction > (t2). The program hangs in 30-50% of the executions right before the call > to entitymanager.find() (used to retrieve the object in t2). By looking > at the JVM dump, I can see the following deadlock: > 1LKDEADLOCKDeadlock detected !!! > NULL - > NULL > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > 3LKDEADLOCKWTRis waiting for: > 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: > 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) > 3LKDEADLOCKWTRwhich is waiting for: > 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: > 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > > I'm using IBM JVM 5 (J2RE 5.0 IBM J9 2.3 Windows XP x86-32 build > j9vmwi3223-20061001) and OpenJPA Runtime Enhancement. > > Is this a known issue? > > I can provide the test program, persistence.xml, etc. > > -- > Best regards, > Vlad Tatavu > Provisioning & Orchestration Development, IBM Tivoli Toronto > [EMAIL PROTECTED] > Office (905) 413-3853 >
Re: Deadlock when insert in t1 and find in t2
Runner.java:460) 4XESTACKTRACE at org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.runTests(RemoteTestRunner.java:673) 4XESTACKTRACE at org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.run(RemoteTestRunner.java:386) 4XESTACKTRACE at org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.main(RemoteTestRunner.java:196) 3XMTHREADINFO "Finalizer thread" (TID:0x41B36200, sys_thread_t:0x41DE154C, state:B, native ID:0x0FF8) prio=5 4XESTACKTRACE at java/lang/ClassLoader.loadClass(ClassLoader.java:563(Compiled Code)) 4XESTACKTRACE at java/lang/Class.forNameImpl(Native Method) 4XESTACKTRACE at java/lang/Class.forName(Class.java:160(Compiled Code)) 4XESTACKTRACE at org/apache/openjpa/lib/util/TemporaryClassLoader.loadClass(TemporaryClassLoader.java:55(Compiled Code)) 4XESTACKTRACE at org/apache/openjpa/lib/util/TemporaryClassLoader.loadClass(TemporaryClassLoader.java:40(Compiled Code)) 4XESTACKTRACE at java/lang/Class.forNameImpl(Native Method) 4XESTACKTRACE at java/lang/Class.forName(Class.java:160(Compiled Code)) 4XESTACKTRACE at org/apache/openjpa/enhance/PCClassFileTransformer.needsEnhance(PCClassFileTransformer.java:171(Compiled Code)) 4XESTACKTRACE at org/apache/openjpa/enhance/PCClassFileTransformer.transform(PCClassFileTransformer.java:117(Compiled Code)) 4XESTACKTRACE at sun/instrument/TransformerManager.transform(TransformerManager.java:141(Compiled Code)) 4XESTACKTRACE at sun/instrument/InstrumentationImpl.transform(InstrumentationImpl.java:174(Compiled Code)) 4XESTACKTRACE at com/ibm/oti/vm/VM.findClassOrNull(Native Method) 4XESTACKTRACE at com/ibm/oti/vm/BootstrapClassLoader.loadClass(BootstrapClassLoader.java:64(Compiled Code)) 4XESTACKTRACE at java/lang/ref/ReferenceQueue.enqueue(ReferenceQueue.java:125) 4XESTACKTRACE at java/lang/ref/Reference.enqueueImpl(Reference.java:93) -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853 "Marc Prud'hommeaux" <[EMAIL PROTECTED]> Sent by: "Marc Prud'hommeaux" <[EMAIL PROTECTED]> 08/01/2007 03:17 PM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: Deadlock when insert in t1 and find in t2 Vlad- I didn't get any attachments in that last message (perhaps they were stripped by the list server). It might be interesting the see the java stack trace parts of the JVM dump, in case that might shed light on the situation. Also, what database are you using? It could be that the deadlock is happening somewhere in the JDBC driver code as well... On Jan 8, 2007, at 11:20 AM, Vlad Tatavu wrote: > > My test program runs in a standalone env, local transactions. Here > are the files: > > > -- > Best regards, > Vlad Tatavu > Provisioning & Orchestration Development, IBM Tivoli Toronto > [EMAIL PROTECTED] > Office (905) 413-3853 > > > "Kevin Sutter" <[EMAIL PROTECTED]> > 08/01/2007 02:01 PM > Please respond to > open-jpa-dev@incubator.apache.org > > > To > open-jpa-dev@incubator.apache.org > cc > Subject > Re: Deadlock when insert in t1 and find in t2 > > > > > > Hi Vlad, > Can you provide a bit more information? Are you running in a managed > environment or a standalone environment? Are these JTA > transactions or > Local transactions? What does your test program look like? What > about the > Entities? Maybe you can attach them to your next reply? > > I see that you are using the J9 JVM. I haven't tried that yet. > I've been > using the "standard" IBM JVM 1.5 at SR3 (or above). I doubt that > this would > make a different, but it might be useful to try this JVM as a test. > > What you are describing is basic JPA functionality, so there must be > something unique with your application or environment. > > Thanks, > Kevin > > On 1/8/07, Vlad Tatavu <[EMAIL PROTECTED]> wrote: > > > > I have a simple test program that uses OpenJPA 0.9.6 to insert an > object > > into a db in one transaction (t1) and retrieve it in another > transaction > > (t2). The program hangs in 30-50% of the executions right before > the call > > to entitymanager.find() (used to retrieve the object in t2). By > looking > > at the JVM dump, I can see the following deadlock: > > 1LKDEADLOCKDeadlock detected !!! > > NULL - > > NULL > > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > > 3LKDEADLOCKWTRis waiting for: > > 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl
Re: Deadlock when insert in t1 and find in t2
My test program runs in a standalone env, local transactions. Here are the files: -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853 "Kevin Sutter" <[EMAIL PROTECTED]> 08/01/2007 02:01 PM Please respond to open-jpa-dev@incubator.apache.org To open-jpa-dev@incubator.apache.org cc Subject Re: Deadlock when insert in t1 and find in t2 Hi Vlad, Can you provide a bit more information? Are you running in a managed environment or a standalone environment? Are these JTA transactions or Local transactions? What does your test program look like? What about the Entities? Maybe you can attach them to your next reply? I see that you are using the J9 JVM. I haven't tried that yet. I've been using the "standard" IBM JVM 1.5 at SR3 (or above). I doubt that this would make a different, but it might be useful to try this JVM as a test. What you are describing is basic JPA functionality, so there must be something unique with your application or environment. Thanks, Kevin On 1/8/07, Vlad Tatavu <[EMAIL PROTECTED]> wrote: > > I have a simple test program that uses OpenJPA 0.9.6 to insert an object > into a db in one transaction (t1) and retrieve it in another transaction > (t2). The program hangs in 30-50% of the executions right before the call > to entitymanager.find() (used to retrieve the object in t2). By looking > at the JVM dump, I can see the following deadlock: > 1LKDEADLOCKDeadlock detected !!! > NULL - > NULL > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > 3LKDEADLOCKWTRis waiting for: > 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: > 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) > 3LKDEADLOCKWTRwhich is waiting for: > 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: > 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: > 3LKDEADLOCKOWNwhich is owned by: > 2LKDEADLOCKTHR Thread "main" (0x0015EC00) > > I'm using IBM JVM 5 (J2RE 5.0 IBM J9 2.3 Windows XP x86-32 build > j9vmwi3223-20061001) and OpenJPA Runtime Enhancement. > > Is this a known issue? > > I can provide the test program, persistence.xml, etc. > > -- > Best regards, > Vlad Tatavu > Provisioning & Orchestration Development, IBM Tivoli Toronto > [EMAIL PROTECTED] > Office (905) 413-3853 >
Deadlock when insert in t1 and find in t2
I have a simple test program that uses OpenJPA 0.9.6 to insert an object into a db in one transaction (t1) and retrieve it in another transaction (t2). The program hangs in 30-50% of the executions right before the call to entitymanager.find() (used to retrieve the object in t2). By looking at the JVM dump, I can see the following deadlock: 1LKDEADLOCKDeadlock detected !!! NULL - NULL 2LKDEADLOCKTHR Thread "main" (0x0015EC00) 3LKDEADLOCKWTRis waiting for: 4LKDEADLOCKMON sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588: 4LKDEADLOCKOBJ java/lang/[EMAIL PROTECTED]/00D4101C: 3LKDEADLOCKOWNwhich is owned by: 2LKDEADLOCKTHR Thread "Finalizer thread" (0x41B36200) 3LKDEADLOCKWTRwhich is waiting for: 4LKDEADLOCKMON sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78: 4LKDEADLOCKOBJ sun/misc/[EMAIL PROTECTED]/00D4E5BC: 3LKDEADLOCKOWNwhich is owned by: 2LKDEADLOCKTHR Thread "main" (0x0015EC00) I'm using IBM JVM 5 (J2RE 5.0 IBM J9 2.3 Windows XP x86-32 build j9vmwi3223-20061001) and OpenJPA Runtime Enhancement. Is this a known issue? I can provide the test program, persistence.xml, etc. -- Best regards, Vlad Tatavu Provisioning & Orchestration Development, IBM Tivoli Toronto [EMAIL PROTECTED] Office (905) 413-3853
