Home » Modeling » EMF » [CDO] OK to attach transient object to CDOTransaction?
| [CDO] OK to attach transient object to CDOTransaction? [message #1777606] |
Thu, 30 November 2017 17:15 |
 Thorsten Schlathölter
Messages: 312
Registered: February 2012
Location: Düsseldorf |
Senior Member |
|
|
Hi,
I have a problem with transient features and CDO. This is very specific and probably may only be understood by people who deeply know about the internals of CDO. So this is the best time to skip this post if you are not.
We are using CDO together with Papyrus. If I create a diagram with stereotypes a couple of stereotype decorations will be created when the diagram is rendered (NOTATION_DECORATIONNODE). It seems like these decorations are meant to be transient as they are added as transient children. Nevertheless they are attached to the CDOTransaction when the decoration objects are attached to the resource.
This can be seen in this stack here:
CdoTransactionImpl(CDOTransactionImpl).registerNew(Map, InternalCDOObject) line: 2525
CdoTransactionImpl(CDOTransactionImpl).registerAttached(InternalCDOObject, boolean) line: 2354
CDOStateMachine$PrepareTransition.execute(InternalCDOObject, CDOState, CDOEvent, Pair<InternalCDOTransaction,List<InternalCDOObject>>) line: 857
CDOStateMachine$PrepareTransition.execute(Object, Enum, Enum, Object) line: 1
CDOStateMachine(FiniteStateMachine<STATE,EVENT,SUBJECT>).process(SUBJECT, EVENT, DATA) line: 172
CDOStateMachine.prepare(InternalCDOObject, Pair<InternalCDOTransaction,List<InternalCDOObject>>) line: 255
CDOStateMachine.attach(InternalCDOObject, InternalCDOTransaction) line: 215
CDOResourceImpl.attached(InternalCDOObject, InternalCDOTransaction) line: 1649
CDOResourceImpl.attached(EObject) line: 1638
CSSDecorationNodeImpl(BasicEObjectImpl).eBasicSetContainer(InternalEObject, int, NotificationChain) line: 1336
CSSDecorationNodeImpl(BasicEObjectImpl).eInverseAdd(InternalEObject, int, Class<?>, NotificationChain) line: 1417
EObjectContainmentEList<E>(EcoreEList<E>).inverseAdd(E, NotificationChain) line: 286
EObjectContainmentEList<E>(NotifyingListImpl<E>).addUnique(E) line: 286
EObjectContainmentEList<E>(AbstractEList<E>).add(E) line: 303
CSSShapeImpl(ViewImpl).insertChild(View, boolean) line: 737
ViewUtil.insertTransientElement(View, View) line: 240
ViewUtil.insertChildView(View, View, int, boolean) line: 221
CreateStereotypeLabelCommand.doExecute() line: 86
CreateStereotypeLabelCommand(RecordingCommand).execute() line: 135
GMFUnsafe$CommandRunnable.run() line: 293
GMFUnsafe.runUnprotected(TransactionalEditingDomain, Runnable) line: 66
GMFUnsafe.write(TransactionalEditingDomain, Runnable) line: 59
GMFUnsafe.write(TransactionalEditingDomain, Command) line: 91
CommandUtil.executeCommand(Command, TransactionalEditingDomain) line: 210
CommandUtil.executeUnsafeCommand(Command, Object) line: 127
AppliedStereotypeNodeLabelDisplayEditPolicy(AbstractAppliedStereotypeDisplayEditPolicy).executeStereotypeLabelCreation(IGraphicalEditPart, Stereotype) line: 481
AppliedStereotypeNodeLabelDisplayEditPolicy(AbstractAppliedStereotypeDisplayEditPolicy).createAppliedStereotypeLabel(Stereotype) line: 351
AppliedStereotypeNodeLabelDisplayEditPolicy(AbstractAppliedStereotypeDisplayEditPolicy).refreshStereotypeLabelStructure(Stereotype) line: 312
AppliedStereotypeNodeLabelDisplayEditPolicy(AbstractAppliedStereotypeDisplayEditPolicy).refreshStereotypeStructure() line: 274
AppliedStereotypeNodeLabelDisplayEditPolicy(AbstractAppliedStereotypeDisplayEditPolicy).refreshNotationStructure() line: 260
AppliedStereotypeNodeLabelDisplayEditPolicy(AbstractAppliedStereotypeDisplayEditPolicy).activate() line: 115
AppliedStereotypeNodeLabelDisplayEditPolicy.activate() line: 39
ClassEditPart(AbstractEditPart).activateEditPolicies() line: 174
ClassEditPart(AbstractEditPart).activate() line: 156
ClassEditPart(AbstractGraphicalEditPart).activate() line: 195
GraphicalEditPart.access$0(GraphicalEditPart) line: 1
ClassEditPart(GraphicalEditPart).activate() line: 205
ClassEditPart(NamedElementEditPart).activate() line: 232
ModelEditPart(AbstractEditPart).activate() line: 160
ModelEditPart(AbstractGraphicalEditPart).activate() line: 195
GraphicalEditPart.access$0(GraphicalEditPart) line: 1
ModelEditPart(GraphicalEditPart).activate() line: 205
ModelEditPart(DiagramEditPart).activate() line: 349
RenderedDiagramRootEditPart(AbstractEditPart).addChild(EditPart, int) line: 215
RenderedDiagramRootEditPart(SimpleRootEditPart).setContents(EditPart) line: 105
DiagramGraphicalViewer(AbstractEditPartViewer).setContents(EditPart) line: 617
DiagramGraphicalViewer.setContents(EditPart) line: 352
DiagramGraphicalViewer(AbstractEditPartViewer).setContents(Object) line: 626
UmlClassDiagramForMultiEditor(DiagramEditor).initializeGraphicalViewerContents() line: 872
UmlClassDiagramForMultiEditor(DiagramEditor).initializeGraphicalViewer() line: 865
UmlClassDiagramForMultiEditor(DiagramEditorWithFlyOutPalette).initializeGraphicalViewer() line: 116
UmlClassDiagramForMultiEditor(DiagramDocumentEditor).initializeGraphicalViewer() line: 174
UmlClassDiagramForMultiEditor(SynchronizableGmfDiagramEditor).initializeGraphicalViewer() line: 350
UmlClassDiagramForMultiEditor(UMLDiagramEditor).initializeGraphicalViewer() line: 534
UmlClassDiagramForMultiEditor(DiagramEditor).createGraphicalViewer(Composite) line: 807
UmlClassDiagramForMultiEditor.createGraphicalViewer(Composite) line: 112
UmlClassDiagramForMultiEditor(GraphicalEditor).createPartControl(Composite) line: 171
UmlClassDiagramForMultiEditor(DiagramEditor).createPartControl(Composite) line: 1580
UmlClassDiagramForMultiEditor(DiagramEditorWithFlyOutPalette).createPartControl(Composite) line: 328
UmlClassDiagramForMultiEditor(DiagramDocumentEditor).createPartControl(Composite) line: 1514
UmlClassDiagramForMultiEditor(UmlGmfDiagramEditor).createPartControl(Composite) line: 245
EditorPart.createEditorPartControl(Composite, IEditorPart) line: 297
EditorPart.createPartControl(Composite) line: 199
TabFolderPart.createChildPart(Object) line: 1065
TabFolderPart.createTabItem(PartLists, Object, int) line: 986
TabFolderPart.synchronize2(PartLists) line: 900
RootPart.synchronize2(PartLists) line: 139
SashWindowsContainer.refreshTabsInternal() line: 709
Once the objects are attached to the transaction they are commited with the next commit. So whenever a Diagram with stereotype is loaded into a CDOTransaction and is displayed in a DiagramEditor, the decorations are created making the CDOTransaction dirty. Next commit possibly writes hundrets of actually transient objects into the repository. This happens over and over whenever the diagram is loaded in a new CDOTransaction.
I would propose to change the implementation of CDOResourceImpl
in such a way:
public void attached(EObject object)
{
if (!FSMUtil.isTransient(this))
{
InternalCDOView view = cdoView();
if (view instanceof InternalCDOTransaction) // Bug 376075
{
InternalCDOTransaction transaction = (InternalCDOTransaction)view;
InternalCDOObject cdoObject = FSMUtil.adapt(object, transaction);
if (CDOUtil.isLegacyObject(cdoObject))
{
if (!FSMUtil.isTransient(cdoObject))
{
// Bug 352204
return;
}
}
// Do not attach if container itself is transient
EObject eContainer = cdoObject.eContainer();
if (eContainer != null)
{
CDOObject cdoContainer = CDOUtil.getCDOObject(eContainer);
if (cdoContainer != null && cdoContainer.cdoState() == CDOState.TRANSIENT)
{
return;
}
}
// Do not attach if feature is transient
EReference containmentFeature = object.eContainmentFeature();
if (containmentFeature != null && !EMFUtil.isPersistent(containmentFeature))
{
return;
}
attached(cdoObject, transaction);
}
}
}
Note that there is another proposed fix that checks if the container itself is transient.
I am sure that the described behaviour is faulty. I just wonder if this is the right place for a fix. I think only non transient objects should be attached to a CDOResource - right? On the other hand I wonder why this issue has not yet popped up? There are other transient features outside of the Notation model world - right?
And I have already found an issue with this fix because sometimes in the Notation model children are moved from transient to persistent and this is not recognized by CDO. Thus if the object is not attached during its transient phase it will not be correctly attached in the persistent phase which finally results in the creation of external references...
Anyone out there who can say something about this issue?
Thanks in advance
Thorsten
[Updated on: Thu, 30 November 2017 17:38] Report message to a moderator |
|
|
Goto Forum:
Current Time: Thu Apr 25 08:42:01 GMT 2024
Powered by FUDForum. Page generated in 0.02752 seconds |
] 
Search
Help
Register
Login
Home
