Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 is currently offline Thorsten SchlathölterFriend
Messages: 306
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

Previous Topic:[CDO][4.6] Request with lower cased Table Name gives an error
Next Topic:Ecore2GenModel with refGenModel
Goto Forum:
  


Current Time: Thu Jun 21 22:16:33 GMT 2018

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

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

Back to the top