Here is an example from a Filter log file (ARS 7.1.0 Patch 007) showing the
Filter doing the delete.
<FLTR> <TID: 0000000006> <RPC ID: 0000002826> <Queue: Escalation> <Client-RPC:
390603 >
<USER: AR_ESCALATOR (Pool 1) > /* Thu Jan 21 2010 04:22:41.1471 */
Checking "Freds Test Filter"
<FLTR> <TID: 0000000006> <RPC ID: 0000002826> <Queue: Escalation> <Client-RPC:
390603 >
<USER: AR_ESCALATOR (Pool 1) > 0: Process
<FLTR> <TID: 0000000006> <RPC ID: 0000002826> <Queue: Escalation> <Client-RPC:
390603 >
<USER: AR_ESCALATOR (Pool 1) > Application-Delete-Entry
"01:CA:RecordLocks" LCK000007380319
Looking at the Escalation Log it definitely waited until all Filter actions
completed before moving on to the next record.
Actually if you have a lot of records to delete I would make the escalation run
in its own thread pool (AR System Administration Console -> System -> General
-> Server Information -> Ports and Queues tab
Set an RPC Prog Number of 390603, Min Threads and Max threads to however many
escalation threads you want.
When you define your escalation select a separate pool for this escalation. If
no pool is selected then the escalation will run in Pool 1.
FYI: Application-Query-Delete-Entry does each delete in a separate
transaction. You can see it do an individual select for each record to delete
by watching the SQL log.
Fred
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky
Sent: Thursday, January 21, 2010 1:25 PM
To: arslist@ARSLIST.ORG
Subject: Re: Delete entry
Hi Joe,
I have to disagree with you here.
Any filter-actions resulting from an Escalation Set-Fields/Push-Fields
operation will be performed in the same thread. I have seen hundreds of
log files to prove this.
I would use the exact same escalation qualification as JK suggested:
'Submit Date' < ( $TIMESTAMP$ - 86400)
I would then have a single run-process action to do the:
Application-Delete-Entry "$SCHEMA$" $1$
Each delete will then take place in a separate transaction.
If you do an Application-Query-Delete-Entry that handles multiple deletes,
it will take place inside a single transaction that will be rolled back if
any of the deletes fail. This use a lot of resources, especially if you
have attachments on the form.
I would suggest that you put an index on the field, and that you run it as
often as possible. Maybe each hour or so, or maybe even every 7 minutes if
you have a lot of records to delete. This will minimize the impact on
other escalations, as each run will take less time.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> That's actually not true.. Filters use a different thread than
> Escalations..
> Let me explain further what I learnt in a performance tuning class years
> ago
> (version 4 days) and I do not think this has changed with the later
> versions..
>
> When an escalation does what it has to do, it terminates its job and
> exits..
> and it runs with a specific thread ID (I do not recall it by memory what
> that ID is but its something like 600630??). But that's besides the
> point..
>
> The filter that actually does the delete does not use the same thread
> number
> as the escalation (try thread logging and you will see this).
>
> So when you have an escalation do what it has to do, namely the first
> phase
> operation of Set Fields, it does that and it doesn't really care if the
> Filter does or does not execute the operations defined to fire on Modify
> when the $USER$ is the escalation user.. Filters when triggered fire and
> utilize a different thread. So the deletes that would be triggered as a
> result of the Modify operation by the Escalation will be independent of
> that
> Escalation thread, and the escalation thread exits before all of the
> deleted
> occur, thus being available to any other escalations that may be designed
> to
> immediately follow..
>
> Joe
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org]on Behalf Of LJ Longwing
> Sent: Thursday, January 21, 2010 12:31 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Delete entry
>
>
> But Joe, yes the set field happens in phase 1, but the delete action
> happening on the record itself is still a phase 3 action. Either way the
> Escalation has to wait for each record to 'process' before it goes onto
> the
> next record, so delete from the escalation vs delete from a filter on the
> record will cause the escalation thread to still wait, so I'm not sure I
> agree with your statements.
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza
> Sent: Thursday, January 21, 2010 10:25 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Delete entry
>
> Fred,
>
> You are right in that calculation-wise it will not really have any
> benefit.
>
> But doing a delete in an escalation is not the best way - Delete is a 2nd
> phase operation and is queued. You do not want to hold the escalation
> thread
> longer than it should for this queue to complete.
>
> So having a filter aid the escalation to actually do the delete and the
> escalation only to mark the record to be deleted is a better approach as
> set
> fields is a fast operation that happens on the first phase of the
> transaction..
>
> Joe
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org]on Behalf Of Grooms, Frederick W
> Sent: Thursday, January 21, 2010 12:16 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Delete entry
>
>
> Since it is on the right side of the equation and not using any fields
> from
> the form the Escalation should only do the calculation once.
>
> As for setting a field and having a Filter do the delete, that is my
> preferred method as well
>
> Fred
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza
> Sent: Thursday, January 21, 2010 10:51 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Delete entry
>
> **
> John,
>
> Should work but I'd make the process a little more data driven..
>
> Instead of having the escalation calculate all this and chocking an
> escalation thread, I'd set that delete time to a temp field at the time of
> submitting the record. For e.g.. create a temp field called
> ztmpDeleteTime.
> Set the time $TIMESTAMP$ + 86400 to it using a filter..
>
> Then have the Escalation check 'ztmpDeleteTime' < $TIMESTAMP$ and mark the
> record for deletion using another temp field that you have that escalation
> set say 'ztmpDelete' to Y.. Do not have the escalation delete it again for
> the purpose of not choking the escalation thread. Have a filter that
> performs that delete when the record is marked for deletion and the $USER$
> is the escalation user. It would be more efficient especially over a
> large
> number of records..
>
> Joe
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org]on Behalf Of John Kelley
> Sent: Thursday, January 21, 2010 11:39 AM
> To: arslist@ARSLIST.ORG
> Subject: Delete entry
>
> Hi All
>
> Brain cramp today
> Can someone confirm that this statement is true!
> I am performing a delete action in an escalation for deleting all items in
> a
> form 24 hours and beyond.
> Let me rephrase
> I want to leave items in the form for 24 hours from the submit date.
>
> 'Submit Date' < ( $TIMESTAMP$ - 86400)
>
>
> Sys:Action
> ARS 7.1
>
> Thanks JK
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
