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

Transaction Options

The TransactionalCommandStack.execute() method accepts a map of options defined by the Transaction interface that determine how changes occurring during the transaction are handled:
  • OPTION_NO_NOTIFICATIONS: changes are not included in post-commit change events, so they are not sent to listeners
  • OPTION_NO_TRIGGERS: changes are not included in pre-commit change events, so they are not sent to triggers
  • OPTION_NO_VALIDATION: changes are not validated
  • OPTION_NO_UNDO: changes are not recorded for undo/redo and rollback. Use with extreme caution
  • OPTION_UNPROTECTED: implies OPTION_NO_UNDO, OPTION_NO_VALIDATION, and OPTION_NO_TRIGGERS. In addition, permits writing to the resource set even in an otherwise read-only context. Use with even more extreme caution. There are almost no situations in which this is a safe or reasonable option to apply to a transaction. Exceptions are cases where the transaction is updating objects that no other transaction in any other thread could yet have observed.

These options are all boolean-valued. They all default to false.

Transaction Options
[ as SVG]

Another option, OPTION_IS_UNDO_REDO_TRANSACTION is merely informative. It is applied by the transaction API, itself, to indicate to clients that a transaction's changes result from undo or redo of a Command. Listeners, on receiving notification of changes in the resource set, can look for this option if they need to distinguish between changes that occurred in the original execution of a command versus undo or redo of a command. It would be highly unual for a client of the transaction API to apply this option.

TransactionalCommandStack stack;
Library library;

// don't tell the UI that we are changing the library name
stack.execute(
    SetCommand.create(domain, library,
        EXTLibraryPackage.Literals.LIBRARY__NAME, "Secret Name"),
    Collections.singletonMap(
            Transaction.OPTION_NO_NOTIFICATIONS, Boolean.TRUE));

Most of these options apply only to read/write transactions. They have no effect on read-only transactions, except only the OPTION_NO_NOTIFICATIONS. Reading the resource set can cause such changes as proxy resolution and resource loading, which generate change events, although they do not indicate changes to the abstract state of the data.

The TransactionalCommandStack implementations of the undo() and redo() methods use the following options for the transactions created for undo and redo of commands:

  • OPTION_NO_UNDO: because we are undoing or redoing a command whose changes we have already recorded, there is no need to record anew
  • OPTION_NO_TRIGGERS: triggers performed during execution were recorded and are automatically undone; any additional changes would be inappropriate
  • OPTION_NO_VALIDATION: there is no need to validate a reversion to a previous state of the data
  • OPTION_IS_UNDO_REDO_TRANSACTION: the transaction's changes are simply undoing or redoing changes made previously

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