db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-4129) jvm level Deadlock between 2 threads accessing the same connection
Date Tue, 26 Oct 2010 22:33:19 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924986#action_12924986
] 

Dag H. Wanvik edited comment on DERBY-4129 at 10/26/10 6:32 PM:
----------------------------------------------------------------

Saw similar code (acessing store without synchronizing on rootConnection as most JDBC API
methods do to be thread safe): cf. this stack taken from RAFCOntainer4 (while investigating
DERBY-4741):

Output trace from RAFContainer4:

   lcc=org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext@1e2befa

   java.lang.Exception: Stack trace
   at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:494)
   at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:244)
   at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:214)
   at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:671)
   at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190)
   at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295)
   at org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(FileContainer.java:2452)
   at org.apache.derby.impl.store.raw.data.FileContainer.getPage(FileContainer.java:2502)
   at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(BaseContainerHandle.java:319)
   at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:150)
   at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:37)
   at java.io.FilterInputStream.read(FilterInputStream.java:66)
   at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:131)
   at org.apache.derby.impl.jdbc.UTF8Reader.fillBuffer(UTF8Reader.java:415)
   at org.apache.derby.impl.jdbc.UTF8Reader.skip(UTF8Reader.java:232)
   at org.apache.derby.impl.jdbc.StoreStreamClob.getReader(StoreStreamClob.java:236)
   at org.apache.derby.impl.jdbc.ClobUpdatableReader.updateReaderIfRequired(ClobUpdatableReader.java:210)
   at org.apache.derby.impl.jdbc.ClobUpdatableReader.read(ClobUpdatableReader.java:120)
   at InterruptTestClob$WorkerThread.run(InterruptTestClob.java:171)

I don't believe this stack holds the monitor on rootConnection.... since none of the JDBC
methods seem grab it. I note that UTF8Reader#fillBuffer *does* call EmbedConnection#setupContextStack,
cf the fact that lcc is set when retrieved via getContext from RAFContainer4.

Additionally, the Clob code doesn't ever call ConnectionChild#handleException to clean up
errors (close connection or shut down database) - EmbedClob does, at least in some cases.
 In the above case, this meant that an error thrown from RAFContainer4 (FILE_IO_INTERRUPTED,
database level), seen wrapped as an IOException by the Clob#read call, did not lead to Derby
shutting down until the next operation against the Connection was initiated and hit a problem..
Is this the way it is intended to be? I think the CLOB code should both synchronize and handle
errors as the rest of the JDBC code does?


      was (Author: dagw):
    Saw similar code (acessing store without synchronizing on rootConnection as most JDBC
API methods do to be thread safe): cf. this stack taken from RAFCOntainer4 (while investigating
DERBY-4741):

Output trace from RAFContainer4:

   lcc=org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext@1e2befa

   java.lang.Exception: Stack trace
   at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:494)
   at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:244)
   at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:214)
   at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:671)
   at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190)
   at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295)
   at org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(FileContainer.java:2452)
   at org.apache.derby.impl.store.raw.data.FileContainer.getPage(FileContainer.java:2502)
   at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(BaseContainerHandle.java:319)
   at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:150)
   at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:37)
   at java.io.FilterInputStream.read(FilterInputStream.java:66)
   at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:131)
   at org.apache.derby.impl.jdbc.UTF8Reader.fillBuffer(UTF8Reader.java:415)
   at org.apache.derby.impl.jdbc.UTF8Reader.skip(UTF8Reader.java:232)
   at org.apache.derby.impl.jdbc.StoreStreamClob.getReader(StoreStreamClob.java:236)
   at org.apache.derby.impl.jdbc.ClobUpdatableReader.updateReaderIfRequired(ClobUpdatableReader.java:210)
   at org.apache.derby.impl.jdbc.ClobUpdatableReader.read(ClobUpdatableReader.java:120)
   at InterruptTestClob$WorkerThread.run(InterruptTestClob.java:171)

I don't believe this stack holds the monitor on rootConnection.... since none of the JDBC
methods seem grab it. I note that UTF8Reader#fillBuffer *does* call EmbedConnection#setupContextStack,
cf the fact that lcc is set. 

Additionally, the Clob code doesn't ever call ConnectionChild#handleException to clean up
errors (close connection or shut down database) - EmbedClob does, at least in some cases.
 In the above case, this meant that an error thrown from RAFContainer4 (FILE_IO_INTERRUPTED,
database level), seen wrapped as an IOException by the Clob#read call, did not lead to Derby
shutting down until the next operation against the Connection was initiated and hit a problem..
Is this the way it is intended to be? I think the CLOB code should both synchronize and handle
errors as the rest of the JDBC code does?

  
> jvm level Deadlock between 2 threads accessing the same connection
> ------------------------------------------------------------------
>
>                 Key: DERBY-4129
>                 URL: https://issues.apache.org/jira/browse/DERBY-4129
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, SQL, Store
>    Affects Versions: 10.4.2.0
>         Environment: Linux 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:36:49 EST 2008 i686
i686 i386 GNU/Linux
>            Reporter: Malchenko Inna
>         Attachments: BlobDeadlock.java, threaddump.txt
>
>
> Threads working with embedded derby get deadlocked.
> Thread dump:
> Found one Java-level deadlock:
> =============================
> "http-8080-13":
>   waiting to lock monitor 0x09d1a37c (object 0x9560fcd8, a org.apache.derby.impl.store.raw.data.BaseContainerHandle),
>   which is held by "dwc.ma.MAJobsManager:dwc.ma.MAManager"
> "dwc.ma.MAJobsManager:dwc.ma.MAManager":
>   waiting to lock monitor 0x09d1a57c (object 0x93da0180, a org.apache.derby.impl.store.raw.data.StoredPage),
>   which is held by "http-8080-13"
> Java stack information for the threads listed above:
> ===================================================
> "http-8080-13":
> 	at java.util.Observable.deleteObserver(Observable.java:78)
> 	- waiting to lock <0x9560fcd8> (a org.apache.derby.impl.store.raw.data.BaseContainerHandle)
> 	at org.apache.derby.impl.store.raw.data.BasePage.releaseExclusive(Unknown Source)
> 	- locked <0x93da0180> (a org.apache.derby.impl.store.raw.data.StoredPage)
> 	at org.apache.derby.impl.store.raw.data.CachedPage.releaseExclusive(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.StoredPage.releaseExclusive(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BasePage.unlatch(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(Unknown Source)
> 	at java.io.DataInputStream.readFully(DataInputStream.java:176)
> 	at java.io.DataInputStream.readFully(DataInputStream.java:152)
> 	at org.apache.derby.iapi.types.SQLBinary.readExternal(Unknown Source)
> 	at org.apache.derby.iapi.types.SQLBinary.getValue(Unknown Source)
> 	at org.apache.derby.iapi.types.SQLBinary.getBytes(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedResultSet.getBytes(Unknown Source)
> 	at dwc.ma.MAOrderProcessor.loadData(MAOrderProcessor.java:147)
> 	- locked <0x91f211b0> (a java.lang.Object)
> 	- locked <0x91f6a068> (a dwc.ma.MAOrderProcessor)
> 	at dwc.ma.MAOrderProcessor.generateBundlesForUser(MAOrderProcessor.java:538)
> 	- locked <0x91f6a068> (a dwc.ma.MAOrderProcessor)
> 	at dwc.ma.MARequestProcessor$HBundleRequest.process(MARequestProcessor.java:239)
> 	at dwc.ma.MARequestProcessor.processRequest(MARequestProcessor.java:39)
> 	at dwc.ma.doProc.doPost(doProc.java:92)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:738)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:595)
> "dwc.ma.MAJobsManager:dwc.ma.MAManager":
> 	at org.apache.derby.impl.store.raw.data.BasePage.releaseExclusive(Unknown Source)
> 	- waiting to lock <0x93da0180> (a org.apache.derby.impl.store.raw.data.StoredPage)
> 	at org.apache.derby.impl.store.raw.data.CachedPage.releaseExclusive(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.StoredPage.releaseExclusive(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BasePage.update(Unknown Source)
> 	at java.util.Observable.notifyObservers(Observable.java:142)
> 	at java.util.Observable.notifyObservers(Observable.java:98)
> 	at org.apache.derby.impl.store.raw.data.BaseContainerHandle.informObservers(Unknown
Source)
> 	at org.apache.derby.impl.store.raw.data.BaseContainerHandle.close(Unknown Source)
> 	- locked <0x9560fcd8> (a org.apache.derby.impl.store.raw.data.BaseContainerHandle)
> 	at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.close(Unknown Source)
> 	at org.apache.derby.impl.store.access.conglomerate.GenericController.close(Unknown Source)
> 	at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.closeForEndTransaction(Unknown
Source)
> 	at org.apache.derby.impl.store.access.RAMTransaction.closeControllers(Unknown Source)
> 	at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source)
> 	at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown
Source)
> 	at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown
Source)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.commitIfAutoCommit(Unknown Source)
> 	at org.apache.derby.impl.jdbc.ConnectionChild.commitIfAutoCommit(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.resultSetClosing(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedResultSet.close(Unknown Source)
> 	- locked <0x91f0b7d0> (a org.apache.derby.impl.jdbc.EmbedConnection30)
> 	at dwc.ma.MAStatsProcessor$UserStatsBundlesProc.run(MAStatsProcessor.java:117)
> 	at dwc.ma.MAJobsManager$Runner.run(MAJobsManager.java:84)
> 	- locked <0x91fce338> (a java.util.LinkedList)
> 	at java.lang.Thread.run(Thread.java:595)
> Found 1 deadlock.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message