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:
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.
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.
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.