Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse EMF Model Transaction Development Guide
Previous Page Home Next Page

Extending the Transactional Editing Domain

Clients that have special requirements in the management of transactions can extend virtually all aspects of the transactional editing domain API. As is usual in EMF, the transaction API defines a number of InteralXyz interfaces corresponding to the interfaces that are intended for public consumption. A valid editing domain implementation must implement the InternalTransactionalEditingDomain interface, a transaction the InternalTransaction interface, and a command stack the InternalTransactionalCommandStack interface. Of course, it is highly recommend to extend the default implementations of all of these interfaces.

Transaction Extensibility API
[ as SVG]

The InternalTransactionalEditingDomain interface specifies the transaction lifecycle API, from activating a transaction through to deactivating it, with the intermediate stage of processing pre-commit listeners and executing their trigger commands on the InternalTransactionalCommandStack. The editing domain also keeps track of which of possibly numerous transactions in a nested structure on one or more threads is currently active, and implements the transfer of ownership from one thread to another in the privileged runnable mechanism.

Transaction Validators

The TransactionalEditingDomainImpl class has an associated Factory for the construction of TransactionValidators. For each root-level transaction that the editing domain activates, it uses its factory to create a validator that will validate the transaction when it commits, as well as tracking the notifications that will be sent to pre- and post-commit listeners. There are two kinds of validator: read-only and read/write, according to the nature of the transaction.

Transaction Validator API
[ as SVG]

Extensions of the editing domain may install their own validator factories to customize their validators to set different options using the EMF Validation Framework's live validation API. For example, a client may want set specific constraint filters or provide arbitrary client-specific data to validation listeners. See the EMF Validation Framework documentation for details.


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


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire