×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.