Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO Concurrent Modfiication Exception
CDO Concurrent Modfiication Exception [message #1761211] Tue, 09 May 2017 01:48 Go to next message
Gabe Colburn is currently offline Gabe ColburnFriend
Messages: 28
Registered: December 2012
Junior Member
I've been developing an application using EMF, CDO, RAP/E4.

When a view part is displayed it opens a cdo transaction, and performs jface databinding between the widgets and the objects retrieved from the transaction.

A session listener is used to receive notification of changes by other clients. On such an event, the transaction in the view part is rolled back. The decision was that which ever client commits first wins and other clients will rollback rather than deal with merging.

Occasionally I observe the stracktrace beneath indicating concurrent modification, but I have had difficulty generating the error in a repeatable manner, making it rather difficult to pin down. It happens in perhaps 1/20 commits. Has anyone seen this before?

At first I thought perhaps the issue was accessing the shared transaction object possibly from multiple threads, but it sounds like CDOTransaction objects are generally thread safe. I would appreciate any advice.

Would I be correct to assume this error is being thrown on the CDO Server side and not the client side?

I'm using CDO 4.5.0.v20160607-1254

Thanks!

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at org.eclipse.emf.cdo.common.lock.CDOLockUtil.createLockState(CDOLockUtil.java:67)
at org.eclipse.emf.cdo.internal.server.Repository.toCDOLockStates(Repository.java:1832)
at org.eclipse.emf.cdo.internal.server.Repository.lock(Repository.java:1773)
at org.eclipse.emf.cdo.internal.server.Repository.lock(Repository.java:1727)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.LockObjectsIndication.indicating(LockObjectsIndication.java:66)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.indicating(CDOServerIndication.java:107)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:100)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:73)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerWriteIndication.execute(CDOServerWriteIndication.java:39)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.Signal.run(Signal.java:162)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Re: CDO Concurrent Modfiication Exception [message #1761347 is a reply to message #1761211] Wed, 10 May 2017 06:12 Go to previous messageGo to next message
Gabe Colburn is currently offline Gabe ColburnFriend
Messages: 28
Registered: December 2012
Junior Member
After further debugging, after a commit (one attribute changed on an object), a flurry of CDOSessionLocksChangedEvent notifications are received in the session listener. If I print out when these occur, then sometimes intermittently the concurrent modification is thrown client side.

For editing one string in a text field with databinding to the cdo object about 100 CDOSessionLocksChangedEvent notifications are sent, which seems like a lot for modifying one attribute, but perhaps is related to a number of databinding updates on the form when a CDOSessionInvalidationEvent is received, causing automatic locks on the other objects.

I tried the following setting to not get the lock notifications:
session.options().setLockNotificationMode(LockNotificationMode.OFF);

but this didn't stop the CDOSessionLocksChangedEvent from arriving and periodically causing concurrent modification exceptions. Perhaps I am misunderstanding this option.
Re: CDO Concurrent Modfiication Exception [message #1766577 is a reply to message #1761347] Fri, 23 June 2017 08:51 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Sorry for the late reply! In the past year we've applied some fundamental changes to the locking subsystem. Perhaps you should first try with the newest 4.6 release: http://download.eclipse.org/modeling/emf/cdo/drops/R20170614-0227

Please let us know if that fixes the problem...


Re: CDO Concurrent Modfiication Exception [message #1771560 is a reply to message #1766577] Mon, 28 August 2017 01:59 Go to previous messageGo to next message
Pavel Vlasov is currently offline Pavel VlasovFriend
Messages: 23
Registered: December 2015
Junior Member
Hi Eike,

It looks like I'm facing a similar issue when I have 10 concurrent threads working on the same repository:

org.eclipse.net4j.signal.RemoteException: java.util.ConcurrentModificationException
at org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:141)
at org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:130)
at org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:488)
at org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:62)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:51)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.Signal.run(Signal.java:162)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at org.eclipse.emf.cdo.common.lock.CDOLockUtil.createLockState(CDOLockUtil.java:67)
at org.eclipse.emf.cdo.internal.server.Repository.toCDOLockStates(Repository.java:1983)
at org.eclipse.emf.cdo.internal.server.Repository.doUnlock(Repository.java:2020)
at org.eclipse.emf.cdo.internal.server.Repository.unlock(Repository.java:2004)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.UnlockObjectsIndication.indicating(UnlockObjectsIndication.java:71)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.indicating(CDOServerIndication.java:108)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:100)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:73)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerWriteIndication.execute(CDOServerWriteIndication.java:39)

I'm using Oxygen Release and Orbit R20170516192513. Is the drop you've recommended part of Oxygen? I've checked the versions of some bundles involved - they are the same.
---
Thank you, Pavel.
Re: CDO Concurrent Modfiication Exception [message #1771635 is a reply to message #1771560] Tue, 29 August 2017 03:40 Go to previous messageGo to next message
Pavel Vlasov is currently offline Pavel VlasovFriend
Messages: 23
Registered: December 2015
Junior Member
I've stepped through the code and it looks like that the reason for this exception is that at CDOLockUtil line 67 a set of ReadLockOwners is returned from the lockState:
for (CDOCommonView view : lockState.getReadLockOwners())

The set is unmodifiable, but it is backed by org.eclipse.net4j.util.concurrent.RWOLockManager.LockState.readLockOwners set, which is modifiable. When this set is modified by another thread in org.eclipse.net4j.util.concurrent.RWOLockManager.LockState.doReadLock(CONTEXT) that causes ConcurrentModificationException.

Below are a couple of thoughts regarding how it might be addressed:

A simple solution might be to add synchronized blocks around the original set and return an unmodifiable copy from getReadLockOwners(). I don't know if that would be an acceptable solution because the iteration loop will not see concurrent modifications.

Another option is to protect readLockOwners by a lock, including the iteration loop, or wrap into a SynchronizedSet with Collections.synchronizedSet(). To keep the lock/synchronization encapsulated in the LockState getReadLockOwners() may be replaced by forEachReadLockOwner(Consumer<CONTEXT>).

[Updated on: Tue, 29 August 2017 19:24]

Report message to a moderator

Re: CDO Concurrent Modfiication Exception [message #1771818 is a reply to message #1771635] Wed, 30 August 2017 21:38 Go to previous message
Pavel Vlasov is currently offline Pavel VlasovFriend
Messages: 23
Registered: December 2015
Junior Member
I think I've fixed it. Created a pull request on GitHub - https://github.com/eclipse/cdo/pull/2

[Updated on: Thu, 31 August 2017 00:26]

Report message to a moderator

Previous Topic:Reference ecore model from another ecore model
Next Topic:Displaying EMF model programmatically
Goto Forum:
  


Current Time: Thu Mar 28 14:40:26 GMT 2024

Powered by FUDForum. Page generated in 0.03913 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top