Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 363355

Summary:

[Legacy] Could not lock OIDXX : occurs on element deletion

Product:

[Modeling] EMF

Reporter:

Alex Lagarde <alex.lagarde>

Component:

cdo.legacy

Assignee:

Christian Damus <give.a.damus>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

alex.lagarde, esteban.dugueperoux, stepper, steve.monnier

Version:

4.3

Target Milestone:

---

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
AbstractCDOView	none
Test Case showing that in one scenario of remote changes receiving (invalidation) we have local CDOTransaction dirty	none

Description Alex Lagarde

2011-11-09 11:52:28 EST

Hi everyone !

I've detected another issue with the ordering of changes to integrate when using legacy mode.

I've already seen this issue with the postCommit notifiactions (https://bugs.eclipse.org/bugs/show_bug.cgi?id=361904).

I've got exactly the same issue with the invalidate() method of the AbstractCDOView, where detachedObjects should be treated before changedObjects.

Otherwise, the following use case lead to issue : 
model shared by A & B : 
Element1 containing Element2 (opposite reference)

- User A changes this reference by saying that Element1 now contains a new Element3, and commits
- User B, in its invalidate method, computes the changed objects (Element1) first. So by setting Element3, the eInverseRemove is called on Element2 which becomes detached.

When user B tries to commit, transaction.getDetachedObjects() returns Element2 although it has already been detached by user A. So the transaction is Dirty but should not be. If user B tries to save, he gets the following error : 

org.eclipse.emf.cdo.util.CommitException: Rollback in DBStore: org.eclipse.net4j.util.concurrent.TimeoutRuntimeException: Could not lock OID95:0 within 1000 milli seconds
	at org.eclipse.net4j.util.concurrent.RWLockManager.lock(RWLockManager.java:338)
	at org.eclipse.net4j.util.concurrent.RWLockManager.lock(RWLockManager.java:117)
	at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.lockObjects(TransactionCommitContext.java:763)
	at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:434)
	at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:42)
	at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
	at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:244)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:92)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
	at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:84)
	at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:90)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
	at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:63)
	at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:63)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
	at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)

Comment 1 Alex Lagarde

2011-11-09 12:04:28 EST

Created attachment 206716 [details]
AbstractCDOView

A "dirty" work-around that treats detachedObjects before changedObjects during the invalidation step.

Comment 2 Esteban DUGUEPEROUX

2012-02-07 04:20:22 EST

Created attachment 210629 [details]
Test Case showing that in one scenario of remote changes receiving (invalidation) we have local CDOTransaction dirty

I have attached a Test case, it run a scenario for which we have a dirty CDOTransaction when receiving remote changes (invalidation) while it should not but applying the existing fix (in attachment) it solves this issue. The test case use H2 as repo backend to show a exception at commit we don't have with MEM store :

[ERROR] Rollback in DBStore: java.lang.NullPointerException
	at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.detachObjects(DBStoreAccessor.java:604)
	at org.eclipse.emf.cdo.spi.server.StoreAccessor.doWrite(StoreAccessor.java:84)
	at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.write(StoreAccessorBase.java:150)
	at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:451)
	at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:42)
	at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
	at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:244)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:92)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)

P.S. : the test failed also on master (and the attached test class is this written for master)

Comment 3 Eike Stepper

2012-06-05 07:29:07 EDT

Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems.

Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!

Comment 4 Eike Stepper

2012-08-14 22:50:56 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 5 Eike Stepper

2013-06-03 05:54:16 EDT

Hi Christian, I assign this legacy mode zilla to you, just in case you're ineterested. Don't feel obliged ;-)

Comment 6 Eike Stepper

2013-06-29 12:16:35 EDT

We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.

Comment 7 Steve Monnier

2013-12-10 05:04:52 EST

A fix has been pushed on gerrit and is waiting for review https://git.eclipse.org/r/#/c/19566/

Comment 8 Esteban DUGUEPEROUX

2014-06-10 04:13:15 EDT

Hi Eike,

I have updated the change set to include a new test Bugzilla_363355_Test.testCannotModifyFrozenRevisionOnInvalidation() and update the fix according to this new test.
Could you give me a feedback on this change set?

Thanks.

Comment 9 Esteban DUGUEPEROUX

2014-08-11 11:54:18 EDT

Commited as 4a6afc879e7792bddd32b4391a267e76b3ace92f

Comment 10 Eike Stepper

2020-12-11 10:28:00 EST

Closing.

Comment 11 Eike Stepper

2020-12-11 10:32:08 EST

Closing.