[
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
