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 clear operation.

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.

Return to Archive home page | Return to MIDRANGE.COM home page