When executing the above Execution in a CDO context the following code is executed:
public void removeViewPersistant(final View view) {
if (view != null) {
if ((view.eContainer() != null) && (view.eContainer() instanceof View)) {
// Move the view from the Persistent List to the Transcient Children list
if (!(view instanceof Edge)) {
View container = (View) view.eContainer();
container.getTransientChildren().add(view);
container.getPersistedChildren().remove(view);
}
}
}
}
It turns out that for CDO the order of execution of the following lines is relevant:
container.getTransientChildren().add(view);
container.getPersistedChildren().remove(view);
If the view is added to transientChildren before it is removed from it's persistedChildren container a CDOContainerFeatureDeltaImpl is created which sets the container of the view to null. This Delta is send to the client with no regard to the remove from the persistedChildren. During delta execution on the server a Null Container is processed which in the end leads to the following security exception. The exception is thrown because the revision of the view has neither a container nor a resource.
Die Daten konnten nicht in die Datenbank geschrieben werden. Bitte prüfen Sie die Details.
Rollback in SoxDBStore: java.lang.SecurityException: User Administrator is not allowed to write to DecorationNode@OID268788:0v3
at org.eclipse.emf.cdo.server.internal.security.SecurityManager$WriteAccessHandler.doHandleTransactionBeforeCommitting(SecurityManager.java:1095)
at org.eclipse.emf.cdo.server.internal.security.SecurityManager$WriteAccessHandler.handleTransactionBeforeCommitting(SecurityManager.java:1042)
at org.eclipse.emf.cdo.internal.server.Repository.notifyWriteAccessHandlers(Repository.java:1475)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.notifyBeforeCommitting(TransactionCommitContext.java:507)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.applyIDMappings(TransactionCommitContext.java:471)
at org.eclipse.emf.cdo.spi.server.StoreAccessor.applyIDMappings(StoreAccessor.java:184)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.applyIDMappings(DBStoreAccessor.java:491)
at enco.sox2.workspace.cdo.server.internal.SoxDbStoreAccessor.applyIDMappings(SoxDbStoreAccessor.java:71)
at org.eclipse.emf.cdo.spi.server.StoreAccessor.doWrite(StoreAccessor.java:93)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.doWrite(DBStoreAccessor.java:888)
at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.write(StoreAccessorBase.java:138)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.writeAccessor(TransactionCommitContext.java:1612)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:737)
at enco.sox2.workspace.cdo.server.internal.SoxTransactionCommitContext.write(SoxTransactionCommitContext.java:145)
at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:49)
at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:95)
at org.eclipse.emf.cdo.internal.server.Repository.commitUnsynced(Repository.java:1190)
at org.eclipse.emf.cdo.internal.server.Repository.commit(Repository.java:1170)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:316)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:102)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:117)
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:87)
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.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:66)
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)
If the order of the two lines is changed the code is executed without a problem because the initial remove will detach the view from CDOTransaction which causes a proper deletion.
I wonder if there is a reason for the order in which the two lines are executed. If not I would raise a bug to have the order changed.
] 
Search
Help
Register
Login
Home
)