db-derby-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/DERBY-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristian Waagan updated DERBY-5603:

    Attachment: derby-5603-1a-avoid_concurrentmodification.diff

Attaching patch 1a, which addresses the problem reported.
The simplest fix is to just move the finally-block to an outer try-block. I changed a little
 o don't call clear in a finally block (consistent with clearing other maps, not sure if this
is the best choice)
 o try to close all file handles, even if an IOException is encountered (the first exception
is saved and thrown later, subsequent exceptions are discarded)
 o made getLobHMObj private
 o adjusted comment, I can't see that the code resets the locator value nor nulifies the map

I'm having trouble writing a test for this issue. In my attempts the cleanup has been proper,
so there is nothing left to do when the code reaches the point where the lobFiles-map is cleared.
I don't see the point in trying to write a test where the VM is pushed close to its limits
to force the WeakHashMap-entry to be removed and the finalization to be delayed, if that's
what it takes to trigger this bug.

Jon, do you have a simple repro for this issue?

I'm running the full regression suite now.

Note: The patch is generated with git, use -p1 when applying with patch.
> 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:,
>         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
> 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
>  ... 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


View raw message