jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3065) ConcurrentModificationException in FineGrainedISMLocking
Date Tue, 06 Sep 2011 09:32:12 GMT

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

Jukka Zitting commented on JCR-3065:
------------------------------------

+1 Looks good.

One possible explanation for this is if we have multiple threads running inside the same transaction.
Then the acquireReadLock() method could call the LockMap.addLock() method without acquiring
the writeStateRWLock.

The logic behind the relevant TransactionContext code is that in some cases different parts
of a transaction are performed by different threads, so locks acquired by one part should
apply also to the other parts of the transaction. The assumption here is that even if something
like that happens, the transaction manager should still ensure that only one thread at a time
is executing within the scope of the transaction. Perhaps we should explicitly enforce that?

> ConcurrentModificationException in FineGrainedISMLocking
> --------------------------------------------------------
>
>                 Key: JCR-3065
>                 URL: https://issues.apache.org/jira/browse/JCR-3065
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2.0
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Minor
>             Fix For: 2.3.0
>
>         Attachments: JCR-3065.patch
>
>
> We have a report where the FineGrainedISMLocking throws a ConcurrentModificationException
(stacktrace
> from a Jackrabbit 2.2.x):
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:828)
> 	at org.apache.jackrabbit.core.state.FineGrainedISMLocking$LockMap.hasDependency(FineGrainedISMLocking.java:388)
> 	at org.apache.jackrabbit.core.state.FineGrainedISMLocking.acquireWriteLock(FineGrainedISMLocking.java:138)
> 	at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1848)
> 	at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:113)
> 	at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:563)
> 	at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1457)
> 	at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1487)
> 	at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351)
> 	at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
> 	at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
> 	at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289)
> 	at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
> 	at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
> 	at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
> 	at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
> 	at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42)
> 	at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
> 	at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
> 	at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message