I must admit that I have not really taken logs to verify that (I don't recall if we did that during the training class back then), but that's what we were told in our version 4 performance training class days. I wonder if things changed after that then if filters executed by escalations ride the same thread as you say. And since then have always had filters perform 2nd and 3rd stage operations that usually are handled by list queues and let escalations perform only fast operations.
Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, January 21, 2010 2: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"
