method accepts a map of options defined by the
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
OPTION_NO_TRIGGERS: changes are not included in pre-commit
change events, so they are not sent to
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.
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.
// don't tell the UI that we are changing the library name
EXTLibraryPackage.Literals.LIBRARY__NAME, "Secret Name"),
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
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.