db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5603) EmbedConnection.clearLOBMapping() incorrectly clears lobFiles causing a ConcurrentModificationException
Date Mon, 06 Feb 2012 13:29:59 GMT

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

Kristian Waagan commented on DERBY-5603:
----------------------------------------

The "problem" is that the entries are removed before Derby reaches the code that fails. I
can easily provoke the error if I modify the source code.
Tthere's a WeakHashMap and a finalizer involved, which makes things a bit tricky - at least
on my system.

Are you seeing the issue during high load, or do you know if memory is scarce in the VM when
this happens?
Are you simply creating new LOBs, or are you both growing and shrinking them in the same transaction?
There may be a specific access pattern that triggers the bug.

I see you mention Blob again. I tried to reproduce with Clob. Although this code is shared
between the two, there may a bug in the Blob-implementation that triggers the issue. I'll
try again with a Blob-repro.
                
> EmbedConnection.clearLOBMapping() incorrectly clears lobFiles causing a ConcurrentModificationException
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5603
>                 URL: https://issues.apache.org/jira/browse/DERBY-5603
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.5.1.1, 10.8.2.2
>         Environment: Win 7 64 bit
> JDK 1.6.0_24
>            Reporter: Jon Steinich
>            Assignee: Kristian Waagan
>            Priority: Critical
>         Attachments: derby-5603-1a-avoid_concurrentmodification.diff
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In EmbedConnection.clearLOBMapping()  the code which iterates over lobFiles has a finally
block which clears the Set.  This causes a ConcurrentModificationException to be thrown and
even using a concurrent data structure would still result in only one LOBFile being correctly
closed.
> This will occur anytime the lobFiles Set contains more than 1 LOBFile.
> Stack Trace:
> java.sql.SQLException: Java exception: ': java.util.ConcurrentModificationException'.

>  at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)

>  at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) 
>  at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) 
>  at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)

>  at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)

>  at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) 
>  at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) 
> <lines removed>
> Caused by: java.sql.SQLException: Java exception: ': java.util.ConcurrentModificationException'.

>  at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) 
>  at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
Source) 
>  ... 16 more 
> Caused by: java.util.ConcurrentModificationException 
>  at java.util.HashMap$HashIterator.nextEntry(Unknown Source) 
>  at java.util.HashMap$KeyIterator.next(Unknown Source) 
>  at org.apache.derby.impl.jdbc.EmbedConnection.clearLOBMapping(Unknown Source) 
>  ... 10 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message