[jira] Resolved: (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 ] Kevin Sutter resolved OPENJPA-98. - Resolution: Fixed This problem will be resolved in SR5 of the IBM v5 JDK. The availability of an interim iFix is still being investigated. The Sun v5 JDK does not seem to exhibit this behavior. > 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 > Assigned To: Kevin Sutter > 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. - You can reply to this email to add a comment to the issue online.
[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_12467396 ] Kevin Sutter commented on OPENJPA-98: - IBM has indicated that the fix will be available in SR5 for JDK 5. I'm still checking on an interim iFix. > 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 > Assigned To: Kevin Sutter > 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. - You can reply to this email to add a comment to the issue online.
[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_12466068 ] Kevin Sutter commented on OPENJPA-98: - This looks to be a problem with the IBM JDK. I reported the problem to IBM and I have just tested a possible fix for the problem. So far, it looks good. Since the original problem was intermittent, I guess I can't be sure that it's resolved. But, after a couple days of testing, it looks to be standing up. I am checking on the availability of a patch or updated version. > 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 > Assigned To: Kevin Sutter > 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_12463755 ] Kevin Sutter commented on OPENJPA-98: - We're thinking along the same lines... The super.loadClass just ends up in the same ClassLoader.loadClass code with the same deadlock. Sorry that I didn't post this earlier. > 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 > Assigned To: Kevin Sutter > 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_12463745 ] Marc Prud'hommeaux commented on OPENJPA-98: --- I wonder what would happen if we replaced: return Class.forName(name, resolve, getClass().getClassLoader()); with: return super.loadClass(name, resolve); > 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 > Assigned To: Kevin Sutter > 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_12463732 ] Kevin Sutter commented on OPENJPA-98: - Yes, I already did that printf thing. It varies on exactly which class is "caught", but, of course, it always starts with java.*, or javax.*, or sun.* (since that's the conditional). As far as the rest of the call stack... I attached the javacore to this Issue so you can look at the whole thing. But, the complete finalizer thread is as follows: 3XMTHREADINFO "Finalizer thread" (TID:0x41ED5F00, sys_thread_t:0x42299718, state:B, native ID:0x165C) 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:56(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) > 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 > Assigned To: Kevin Sutter > 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_12463713 ] Marc Prud'hommeaux commented on OPENJPA-98: --- I've never seen any problem like this. It is interesting that the finalizer thread is causing the problem. Do you have a deeper stack for the "Finalizer thread"? Also, I wonder if running your test with the "-verbose:class" would help identify the class in question, and thereby shed some more light on the problem (or alternately putting a printf in TemporaryClassLoader.loadClass()). > 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 > Assigned To: Kevin Sutter > 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_12463636
]
Kevin Sutter commented on OPENJPA-98:
-
I'll take ownership of this report (for now, at least).
I can now reproduce the problem. Using the runtime enhancement and using
previously created database tables, the problem reproduces itself quite easily.
>From looking at the resulting stack traces for the deadlock, the dynamic
>enhancement processing is definitely the source of the problem. If the
>classes were statically enhanced before the execution, this particular problem
>would not surface. But, I don't see any processing within the dynamic
>enhancement class loader that should cause this type of deadlock.
Here are snippets from the javacore thread dump for the two deadlocked threads:
3XMTHREADINFO "main" (TID:0x41DF8C00, sys_thread_t:0x0038B9D8, state:B,
native ID:0x1744) 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
org/apache/openjpa/jdbc/kernel/JDBCStoreManager.getManagedType(JDBCStoreManager.java:562)
4XESTACKTRACE at
org/apache/openjpa/kernel/DelegatingStoreManager.getManagedType(DelegatingStoreManager.java:140)
4XESTACKTRACE at
org/apache/openjpa/kernel/BrokerImpl.newStateManagerImpl(BrokerImpl.java:1136)
4XESTACKTRACE at
org/apache/openjpa/kernel/BrokerImpl.find(BrokerImpl.java:826)
4XESTACKTRACE at
org/apache/openjpa/kernel/BrokerImpl.find(BrokerImpl.java:743)
4XESTACKTRACE at
org/apache/openjpa/kernel/DelegatingBroker.find(DelegatingBroker.java:169)
4XESTACKTRACE at
org/apache/openjpa/persistence/EntityManagerImpl.find(EntityManagerImpl.java:346)
4XESTACKTRACE at
com/ibm/ws/persistence/tests/simple/TestInsertAndFind.test001(TestInsertAndFind.java:51)
:
3XMTHREADINFO "Finalizer thread" (TID:0x41ED6200, sys_thread_t:0x42299718,
state:B, native ID:0x1078) 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))
:
As the "find" operation is performed in the main thread, additional classes
need to be loaded to satisfy the request. As part of that class loading, the
runtime enhancement is kicked off to determine whether the classes being loaded
need to be enhanced or not.
As part of this checking, the following conditional is executed:
if (name.startsWith("java.") || name.startsWith("javax.")
|| name.startsWith("sun."))
return Class.forName(name, resolve, getClass().getClassLoader());
This call to Class.forName() eventually requests the same lock that is already
in place on the Main thread. Everytime I hit this deadlock, it's the same
stack traces. And, it's always at the same spot in the testcode. But, like
Vlad and I have mentioned, it doesn't deadlock on every execution.
My gut reaction at this point is that we have a problem with the IBM JDK. But,
I wanted to post my findings to this Issue to see if this description jogs any
memory bits from the original OpenJPA authors.
Thanks,
Kevin
> 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"
>
[jira] Assigned: (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 ] Kevin Sutter reassigned OPENJPA-98: --- Assignee: Kevin Sutter > 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 > Assigned To: Kevin Sutter > 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_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: Deadlock when insert in t1 and find in t2
Hi Vlad, It might be easier for you to file a JIRA and upload your test case to it. Craig On Jan 9, 2007, at 8:56 AM, Vlad Tatavu wrote: 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)) > 4XE
Re: Deadlock when insert in t1 and find in t2
Fair enough. I saw the Schema Mapping property in your persistence.xml, so I assumed that you were using this feature. I'll try to reproduce it later with this new information. Thanks, Kevin On 1/9/07, Vlad Tatavu <[EMAIL PROTECTED]> wrote: 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* <http://10.2.1.6/> - (452058) driverName: Apache Derby Embedded JDBC Driver driverVersion: *10.2.1.6* <http://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]<[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 >
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
at > org/apache/openjpa/persistence/EntityManagerImpl.find > (EntityManagerImpl.java:320) > 4XESTACKTRACE at > play/TestInsertAndFind.test001(TestInsertAndFind.java:48) > 4XESTACKTRACE at > sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method) > 4XESTACKTRACE at > sun/reflect/NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:64) > 4XESTACKTRACE at > sun/reflect/DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > 4XESTACKTRACE at java/lang/reflect/Method.invoke > (Method.java:615) > 4XESTACKTRACE at > org/junit/internal/runners/TestMethodRunner.executeMethodBody > (TestMethodRunner.java:99) > 4XESTACKTRACE at > org/junit/internal/runners/TestMethodRunner.runUnprotected > (TestMethodRunner.java:81) > 4XESTACKTRACE at > org/junit/internal/runners/BeforeAndAfterRunner.runProtected > (BeforeAndAfterRunner.java:34) > 4XESTACKTRACE at > org/junit/internal/runners/TestMethodRunner.runMethod > (TestMethodRunner.java:75) > 4XESTACKTRACE at > org/junit/internal/runners/TestMethodRunner.run > (TestMethodRunner.java:45) > 4XESTACKTRACE at > org/junit/internal/runners/TestClassMethodsRunner.invokeTestMethod > (TestClassMethodsRunner.java:71) > 4XESTACKTRACE at > org/junit/internal/runners/TestClassMethodsRunner.run > (TestClassMethodsRunner.java:35) > 4XESTACKTRACE at > org/junit/internal/runners/TestClassRunner$1.runUnprotected > (TestClassRunner.java:42) > 4XESTACKTRACE at > org/junit/internal/runners/BeforeAndAfterRunner.runProtected > (BeforeAndAfterRunner.java:34) > 4XESTACKTRACE at > org/junit/internal/runners/TestClassRunner.run(TestClassRunner.java: > 52) > 4XESTACKTRACE at > org/eclipse/jdt/internal/junit4/runner/JUnit4TestReference.run > (JUnit4TestReference.java:38) > 4XESTACKTRACE at > org/eclipse/jdt/internal/junit/runner/TestExecution.run > (TestExecution.java:38) > 4XESTACKTRACE at > org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.runTests > (RemoteTestRunner.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
Re: Deadlock when insert in t1 and find in t2
nternal/runners/TestClassRunner.run(TestClassRunner.java: 52) 4XESTACKTRACE at org/eclipse/jdt/internal/junit4/runner/JUnit4TestReference.run (JUnit4TestReference.java:38) 4XESTACKTRACE at org/eclipse/jdt/internal/junit/runner/TestExecution.run (TestExecution.java:38) 4XESTACKTRACE at org/eclipse/jdt/internal/junit/runner/RemoteTestRunner.runTests (RemoteTestRunner.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
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
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_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/Launcher [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
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 >
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
