# EMF Model Transaction Overview

The transaction framework provides the capability of managing access to an editing domain by multiple reading and writing threads. It also provides a facility to register and share an editing domain amongst different clients and listeners. Resource set listeners are defined in the transaction layer and are provided with notifications in batches. The resource set listener has the option to append changes before the transaction is committed (pre-commit) or receive only the notifications of transactions that were validated and not rolled-back (post-commit). The following are the main extension points and classes to be used with the transaction framework:

1. The extension point org.eclipse.emf.transaction.editingDomains is used to declare an transactional editing domain unique identifier. This identifier can be used by clients to either construct the transactional editing domain if it doesn't already exist or find the editing domain from memory if it already exists.
2. The extension point org.eclipse.emf.transaction.listeners is used to declare listeners that should be automatically attached to an editing domain when it is first constructed. A listener can be registered against all, one or many editing domains.
3. The `TransactionalEditingDomain` has two interfaces called `Registry` and `Factory`. The `Registry` singleton can be used to add new transactional editing domains to the registry using a unique identifier or to retrieve (or construct) an editing domain from its unique identifier. The `Factory` has a default implementation that is used to construct new transactional editing domains. A `TransactionalEditingDomain` allows clients to add and remove their `ResourceSetListeners` as well as allowing clients to perform exclusive reads blocking any other reading / writing threads. Write access is obtained by executing an EMF-style command on the editing domain's command stack.
4. Clients can use the `RecordingCommand` to automatically record the changes made by their subclass so that undo and redo can be done automatically. The client does not need to implement undo and redo in this case.
5. A special `RunnableWithResult` class is provided so that clients can pass instances of this special `Runnable` to the `runExclusive()` method on a `TransactionalEditingDomain` and have their result propagated back to the caller of `runExclusive()`. This can help clients who are querying models and returning results back to the caller.

Please refer to the tutorial Transaction Tutorial.

Copyright (c) 2006, 2007 IBM Corporation and others. All Rights Reserved.