Community
Participate
Working Groups
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)
Created attachment 206716 [details] AbstractCDOView A "dirty" work-around that treats detachedObjects before changedObjects during the invalidation step.
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)
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!!!
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Hi Christian, I assign this legacy mode zilla to you, just in case you're ineterested. Don't feel obliged ;-)
We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.
A fix has been pushed on gerrit and is waiting for review https://git.eclipse.org/r/#/c/19566/
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.
Commited as 4a6afc879e7792bddd32b4391a267e76b3ace92f
Closing.
