You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (Updated) (JIRA)" <ji...@apache.org> on 2012/02/06 12:15:59 UTC
[jira] [Updated] (DERBY-5603) EmbedConnection.clearLOBMapping()
incorrectly clears lobFiles causing a ConcurrentModificationException
[ 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 more:
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 reference.
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: 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