On 05-Aug-2014 09:11 -0500, Briggs, Trevor (TBriggs2) wrote:
<<SNIP>> I haven't used trigger programs much, so I can't say what
happens if the file is updated again while the first invocation of the
trigger program is still running.
Either the result is effective recursion [same thread; trigger
program appearing multiple times in the thread stack] or the result is
concurrent [the trigger program runs also in a different thread].
However, it does seem like a bottleneck waiting to happen.
Concurrency _can be_ a bottleneck for a need often to serialize some
portion of the work, but for the ability to take fuller advantage of
resources, just as easily can eliminate a bottleneck; e.g. explicitly
serialized work could be a bottleneck, mostly for being so slow for lack
of any concurrent work taking full advantage of the potentially
available resources. A Clear Physical File Member (CLRPFM) operation is
work that inhibits concurrency due to the serialization being activated
at a high-level and the clear being a long-running operation. While I/O
can be much longer-running as the amount of rows increases, the amount
of concurrency allowed is extreme in how much better than using the
What happens if you have, say, a batch job that makes hundreds of
updates to the file within a few microseconds?
The database [SQL or native] trigger performs synchronously to the
respective type of /update/ work [e.g. insert, delete, update] so the
work of the trigger is invoked by the database in a serial manner; each
successive row update must await the completion of the work from the
prior trigger activation.
A specific trigger question might best be started\composed as a new
topic\subject [and message thread]; better than being tucked within a
thread with an unrelated /subject/ and nearly incomprehensible opening
post and followups.