Runs the given action as an atomic workspace operation.
After running a method that modifies resources in the workspace, registered listeners receive after-the-fact notification of what just transpired, in the form of a resource change event. This method allows clients to call a number of methods that modify resources and only have resource change event notifications reported at the end of the entire batch.
If this method is called outside the dynamic scope of another such call, this method runs the action and then reports a single resource change event describing the net effect of all changes done to resources by the action.
If this method is called in the dynamic scope of another such call, this method simply runs the action.
The supplied scheduling rule is used to determine whether this operation can be run simultaneously with workspace changes in other threads. If the scheduling rule conflicts with another workspace change that is currently running, the calling thread will be blocked until that change completes. If the action attempts to make changes to the workspace that were not specified in the scheduling rule, it will fail. If no scheduling rule is supplied, then any attempt to change resources will fail. If a non-null
scheduling rule is supplied, this operation must always support cancelation in the case where this operation becomes blocked by a long running background operation.
The AVOID_UPDATE flag controls whether periodic resource change notifications should occur during the scope of this call. If this flag is specified, and no other threads modify the workspace concurrently, then all resource change notifications will be deferred until the end of this call. If this flag is not specified, the platform may decide to broadcast periodic resource change notifications during the scope of this call.
Flags other than AVOID_UPDATE
are ignored.
@param action the action to perform
@param rule the scheduling rule to use when running this operation, or
null
if there are no scheduling restrictions for this operation.
@param flags bit-wise or of flag constants (only AVOID_UPDATE is relevanthere)
@param monitor a progress monitor, or
null
if progressreporting is not desired.
@exception CoreException if the operation failed.
@exception OperationCanceledException if the operation is canceled. If a non-
null
scheduling rule is supplied, cancelation can occur even if no progress monitor is provided.
@see #AVOID_UPDATE
@see IResourceRuleFactory
@since 3.0