[
https://issues.apache.org/jira/browse/DERBY-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201377#comment-13201377
]
Kristian Waagan commented on DERBY-5603:
----------------------------------------
Thank you for the feedback.
It's hard to say exactly what's going on without a repro, but:
o the maps are private to each connection
o the code you pointed at is obviously broken, and will fail if a map with
more than one entry is cleared
o access to the map is synchronized on the connection object
Currently I can only think of the situation where the entries haven't been
cleared the "normal" way for whatever reason, and then the clearing fails due
to the broken code.
I'll wait for more input from the community, and then commit a patch along the
lines of the current suggestion/patch if nothing substantial comes up.
Finally, how often do you see this bug?
Are you running with isolation level read-uncommitted? (may not be relevant,
but there are some issues with LOBs and locking at that level)
Are you in a situation where you could test a build off the head of the 10.8
branch?
That is, 10.8.2.2 + all fixes that have been backported since the release.
Building the jars with 10.8.2.2 + this fix only is also possible of course.
None of these have been tested thoroughly by the community.
> 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
