On 04 Oct 2012 09:44, Åke Olsson wrote:
But we would like to turn on and off the activation of triggers more
or less at will. Status *ENABLED and *DISABLED should work nicely.
The problem is that this operation seems to require private
<ed: exclusive allocation> access to the file almost as much as
ADDPFTRG does - is that really so?
Is there in that case another better way to dynamically switch
triggers on and off?
In such an environment, what is gained by having the work done in a
trigger versus in the application(s) themselves? Pushing the business
logic into the database via triggers, typically is done to ensure that
the work will be performed for every triggered I\O *irrespective* of
what the application is coded to do or not do, beyond that specific I\O
request. Requiring the exclusive lock by CHGPFTRG ensures that the
triggers can not be be disabled while the file is in use by any number
of applications, thus ensuring that the intended business logic was
being applied to every I\O until the change-requester obtained their
exclusive allocation. Otherwise the logging\journal-entries might have
to be reviewed to know which I\O activity had not been triggered, and
then presumably required to have the intended business logic applied
later, to each row according to each I\O action [for which the business
logic was not triggered]; though according to design, the trigger would
still get called for all existing opens that were performed when the
trigger was active, because the trigger is defined in the active ODP.
Seems to me that if the expressed capability to disable and re-enable
the triggers "at will" is required, then the application(s) should
probably be making the decision about which additional business logic
should be performed with that I\O. Or that same logic being used to
decide which additional business logic should be performed with that
I\O, could simply be deferred for invocation from within the triggers,
such that the triggers would remain enabled and the triggered program
would simply return with no additional action taken for that I\O when
deemed appropriate by the added logic.?
Given none of that makes sense for the given scenario, for whatever
reason [e.g. it just *has* to work that way], then I offer instead
that... The application(s) using the file(s) should be designed with
effective failover capability. The design should allow for the
applications to be interrupted and stopped, to include closing the
file(s) [and releasing other resources], and then reactivate [using the
same or different files or possibly even a different database] as
directed by the interrupter. That enables the opportunity for the
Change Physical File Trigger request to complete at a clear boundary;
the time at which the change-requester was able to obtain the exclusive
lock because all applications had closed\unlocked the file(s).