Hi Kelly,
Change your escalation to do the following:
Action 1: Push-Fields to Scheduler ('1' = $1$) and set status to "Running"
Action 2: Push-Fields to Log
Action 3: Push-Fields to Scheduler ('1' = $1$) and set status to "Completed"
Each push is commited to the database immediately after completion.
You would, of course, need to remove the Push-Fields Filter attached to
the Scheduler form.
I tried it, and logged it, and as you can see, each Push-Fields is
committed to the database immediately:
http://www.rrr.se/tmp/rrrLogScheduler.html
Note that I omitted the Push to the Log-form in the test...
Best Regards - Misi, RRR AB, http://www.rrr.se/sv/
> I am working with a scheduling application that uses a one minute interval
> escalation to review and kick off jobs that are set by users.
>
> The problem is that if the job that is kicked off lasts longer than one
> minute, it might get started multiple times. I am looking to modify this
> process so that it will start only once.
>
> Currently, there are two forms, the Scheduler form and the Log form. On
> the Scheduler form there are two fields of interest:
>
> Status
> - Waiting
> - Running
> - Completed
>
> Next Execution (date/time)
>
> The Run escalation looks every minute for entries where 'Status' =
> "Waiting" AND 'Next Execution' < $TIMESTAMP$. Those it finds are set to
> Status "Running".
>
> Filters on the Scheduler form fire for 'Status' = "Running" and create a
> Log form entry with the pertinent job information.
>
> Filters on the Log form fire on Submit and run the job. (For example,
> setting a process flag on entries of a separate form.)
>
> Another escalation on the Log form checks sets their status to Complete,
> which pushes back to the Scheduler form.
> ---------------
>
> The problem is, if the job is data intensive, it can build a large backlog
> of pending transactions that the initial Log entry submission and thus the
> setting of the Scheduler entry 'Status' to "Running" are waiting on. If
> this goes over one minute, as it now is, the escalation will push in
> another transaction to change the Scheduler entry and another large
> backlog of transactions is created. This is bringing my dev server to a
> whimpering halt.
>
> The main problem as I see it is that the once the chain filters starts,
> the following escalation fires can't see that it has started.
>
> Here's my question: If I have a filter in this chain that is set with the
> `! postfix, will it fire immediately, or will it still be a part of the
> chain, just before the other latter stage filter actions?
>
> For example, if I add a flag field to the Scheduler form and change the
> Run escalation to modify that instead:
>
> Run escalation looks on Scheduler form for entries that have 'Status' =
> "Waiting" and 'Next Execution' < $TIMESTAMP$
>
> Scheduler filter (with `! postfix) fires on 'zTmpStatus' = "Running" and
> 'Status' = "Waiting":
> 1.) Set Fields - 'zTmpStatus' to $NULL$ and 'Status' to "Running"
> 2.) Commit Changes
>
> Scheduler filter II (without postfix but with same Run If) fires and
> creates the Log entry to run the job. Job runs for five minutes.
>
> When Run escalation rolls around one minute later, will it see the
> Scheduler entry with a 'Status' of "Running", or still "Waiting"?
>
> Thanks in advance,
>
> Kelly Logan
> Cybernetic Solutions, Inc.
> [EMAIL PROTECTED]
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
