[ 
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

        

Reply via email to