openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Deadlock when insert in t1 and find in t2
Date Tue, 09 Jan 2007 17:25:06 GMT
Fair enough.  I saw the Schema Mapping property in your persistence.xml, so
I assumed that you were using this feature.

            <property name="openjpa.jdbc.SynchronizeMappings"
                value="buildSchema(ForeignKeys=true)"/>

I'll try to reproduce it later with this new information.

Thanks,
Kevin

On 1/9/07, Vlad Tatavu <vtatavu@ca.ibm.com> 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. <class>) 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 <class>
> 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
> vtatavu@ca.ibm.com
> Office (905) 413-3853
>
>
>  *"Kevin Sutter" <kwsutter@gmail.com>*
>
> 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 <class>
> 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...
>
>            <property name="openjpa.Log" value="DefaultLevel=TRACE,
> SQL=TRACE"/>
>
> Let us know what you find out.
>
> Thanks,
> Kevin
>
> On 1/8/07, *Marc Prud'hommeaux* <*mprudhom@apache.org*<mprudhom@apache.org>>
> 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:0x000017B4) 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(URLClassLoader.java:957
> > (Compiled
> > Code))
> > 4XESTACKTRACE          at
> > java/security/AccessController.doPrivileged(AccessController.java:275)
> > 4XESTACKTRACE          at
> > java/net/URLClassLoader.findClass(URLClassLoader.java:487(Compiled
> > Code))
> > 4XESTACKTRACE          at
> > java/lang/ClassLoader.loadClass(ClassLoader.java:606(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/sql/SQLFactoryImpl.newSelect
> > (SQLFactoryImpl.java:40)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/jdbc/kernel/
> > JDBCStoreManager.getInitializeStateResult(JDBCStoreManager.java:367)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/jdbc/kernel/JDBCStoreManager.initializeState
> > (JDBCStoreManager.java:296)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/jdbc/kernel/JDBCStoreManager.initialize
> > (JDBCStoreManager.java:252)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/kernel/DelegatingStoreManager.initialize
> > (DelegatingStoreManager.java:108)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/kernel/ROPStoreManager.initialize
> > (ROPStoreManager.java:54)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/kernel/BrokerImpl.initialize( BrokerImpl.java:870)
> > 4XESTACKTRACE          at
> > org/apache/openjpa/kernel/BrokerImpl.find(BrokerImpl.java:828)
> > 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: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:0x00000FF8) 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
> > *vtatavu@ca.ibm.com* <vtatavu@ca.ibm.com>
> > Office (905) 413-3853
> >
> >
> >
> > "Marc Prud'hommeaux" <*mprudhom@apache.org * <mprudhom@apache.org>>
> > Sent by: "Marc Prud'hommeaux" <*mprudhomapache@gmail.com*<mprudhomapache@gmail.com>
> >
> > 08/01/2007 03:17 PM
> > Please respond to
> > *open-jpa-dev@incubator.apache.org* <open-jpa-dev@incubator.apache.org>
> >
> >
> > To
> > *open-jpa-dev@incubator.apache.org* <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
> >> *vtatavu@ca.ibm.com* <vtatavu@ca.ibm.com>
> >> Office (905) 413-3853
> >>
> >>
> >> "Kevin Sutter" <*kwsutter@gmail.com* <kwsutter@gmail.com>>
> >> 08/01/2007 02:01 PM
> >> Please respond to
> >> *open-jpa-dev@incubator.apache.org* <open-jpa-dev@incubator.apache.org>
> >>
> >>
> >> To
> >> *open-jpa-dev@incubator.apache.org* <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 <*vtatavu@ca.ibm.com* <vtatavu@ca.ibm.com>>
> 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:
> >>> 1LKDEADLOCK    Deadlock detected !!!
> >>> NULL           ---------------------
> >>> NULL
> >>> 2LKDEADLOCKTHR  Thread "main" (0x0015EC00)
> >>> 3LKDEADLOCKWTR    is waiting for:
> >>> 4LKDEADLOCKMON      sys_mon_t:0x41E40548 infl_mon_t: 0x41E40588:
> >>> 4LKDEADLOCKOBJ      java/lang/Object@00D41010/00D4101C:
> >>> 3LKDEADLOCKOWN    which is owned by:
> >>> 2LKDEADLOCKTHR  Thread "Finalizer thread" (0x41B36200)
> >>> 3LKDEADLOCKWTR    which is waiting for:
> >>> 4LKDEADLOCKMON      sys_mon_t:0x0035CD38 infl_mon_t: 0x0035CD78:
> >>> 4LKDEADLOCKOBJ      sun/misc/Launcher
> >> $AppClassLoader@00D4E5B0/00D4E5BC:
> >>> 3LKDEADLOCKOWN    which 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
> >>> *vtatavu@ca.ibm.com* <vtatavu@ca.ibm.com>
> >>> Office (905) 413-3853
> >>>
> >>
> >
> >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message