GMFTools Part 2: Sharing an EditingDomain

In this blog, I will elaborate on how GMFTools facilitates to share the same instance of an EditingDomain across multiple diagram editors.

What is an EditingDomain?

In GMF, each diagram editor works on its own instance of a so called TransactionalEditingDomain. TransactionalEditingDomain is a concept from EMF Transaction. In GMF, it contains an EMF ResourceSet holding the diagram model, its semantic model and all referenced models as well as a command stack for undo/redo support. In addition, each editor registers a WorkspaceSynchronizer to its resource files, making sure external changes are synchronized with the editor's content.

Why share the EditingDomain?

In the default setup, problems occur if two editors operate on the same resources: If both editors change the same resource, saving one will overwrite the changes of the other. This situation already happens when you're using the Related Diagrams feature in the gmfmap model: On double click, it will open a new diagram that is saved in the same resource but in a different editing domain. As the original editor is still open, conflicts can arise quickly.

Another reason for sharing the editing domain is to save memory and performance, especially if you're working on big models with a couple of editors.

In many cases you might want to see changes immediately in all editors without having to save first, e.g. when your editors show different parts or aspects of the same model. GMF has already built-in support for that as it uses EMF's notification mechanism to synchronize the notation (diagram) model with the semantic model.

Consequences of sharing an EditingDomain

Sharing the editing domain across several editors has a number of consequences

• The editors will also share the same command stack. Undo/redo becomes a global operation and can therefore affect other editors than the currently active one.
• For reasons of simplicity, all editors should be saved synchronously, and they will all be either dirty or clean at the same time.
• You should no longer dispose the editing domain when closing an editor. That means, to avoid memory leaks you need strategy for unloading unneeded resources.
  
• The command stack will keep references to unloaded model elements, too, so you might want to have an garbage collecting strategy here as well or at least keep the command history short.

Solution in GMFTools

The solution in GMFTools is based on a WiKi page of GMF and a couple of newsgroup entries combined with our own experiences. It has been recently refactored to reenable the WorkspaceSynchronizer.

It comes in a number of aspectual template changes for the GMF code generator, an additional runtime plug-in and tool support for fixing the type registry, such that it is rather easy to consume even if you're not too familiar with the GMF runtime. Note that so far we have only been using it to generate plain diagram plug-ins, i.e. not for GMF's RCP generator.

The major changes are

• Redirect all creation statements of an editing domain to a new utility class and the dispose statements to an unloading tool.
  
• Make sure to use consistent element types.
• The common behavior of all XXDocumentProvider.ResourceSetInfo has been extracted to avoid synchronization feedback loops.

If you're interested in the details have a look at the WiKi-page.