![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I have a scenario where inspector's synchronize their PDA's at the end of the day (we use SQL Server Merge Replication). When an inspector is done, I'd like to kick off a cleanup process (that code would be in a dts package). The code on the PDA, if the merge replicaton was successful, would send an http request to the same IIS that is used during Merge Replication. *The http call would have to be non-blocking (doesn't matter to the inspector if cleanup was successful, the end of their "sync" should just start the process not wait for it to finish). *For example, if 3 inspector's were sync'ing at approximately the same time, the dts package should execute it's clean-up steps one request at a time. In other words, if the dts package is executing, the other two requests should wait until the 1st one is done. Then the 3rd, should wait for the 2nd to be done. etc. Is this possible? Ideas? Thanks! |
#3
| |||
| |||
|
|
You should have their synch-ups make an entry into a table. Have a job that runs every so ofter (1 minute, 5 minutes, whatever) that checks the table to see if it needs to do any cleanup. If it does, then make the top task as in process, when it's finished, mark the in-process task as complete and/or delete it. If a a task is in-process, the job would do nothing else. You need to consider what to do if a job fails and a process gets marked as in-process and stays that way. Perhaps some sort of time limit where it gets changed back to unprocessed if it's still marked in-process. Robert. "William Campbell" wrote: I have a scenario where inspector's synchronize their PDA's at the end of the day (we use SQL Server Merge Replication). When an inspector is done, I'd like to kick off a cleanup process (that code would be in a dts package). The code on the PDA, if the merge replicaton was successful, would send an http request to the same IIS that is used during Merge Replication. *The http call would have to be non-blocking (doesn't matter to the inspector if cleanup was successful, the end of their "sync" should just start the process not wait for it to finish). *For example, if 3 inspector's were sync'ing at approximately the same time, the dts package should execute it's clean-up steps one request at a time. In other words, if the dts package is executing, the other two requests should wait until the 1st one is done. Then the 3rd, should wait for the 2nd to be done. etc. Is this possible? Ideas? Thanks! |
#4
| |||
| |||
|
|
Thought I'd post under my Managed Newsgroup ID, to see if I could garner more responses. ![]() I had thought of something similar, at first. I was thinking that the HH could send an asp request to write an entry into a database table - this would be quick and would free the HH so they could move on without having to wait. And I was even thinking that this table could then have a trigger that would then launch the more time-consuming part of the "cleanup" process. But, I'd really like to easily only work on ONE cleanup at a time - and I'd like to avoid polling as you suggested. I hate polling! ![]() Especially when 22 of the 24 hours of the day it would be polling for no reason - but limiting to a set time every day would be silly, just because of the certain occassions where the sync happens outside the normal 'syncing window'. Anyhow, I saw that I could skip the whole "trigger" thing by possibly calling the dts package directly. If I could get the HTTP to ASP to call DTS package request to return immediately (and to only run that one dts process at a time). Looks like I could still get it to return quickly by writing to the table and launching the trigger to call the dts package ... but I want to ensure that the cleanup process only runs once at a time. So, if there are 5 requests concurrently...request 1 runs, finishes. request 2 runs, finishes. etc. What about if the dts package contains one step in the process - my custom task (some dll I create). And I set the Package properties to: "Limit the maximum number of tasks executed in parallel to 1"? Would that work? Would the requests then run asynchronously? I mean, if the trigger sends 5 quick requests...but the dts package only runs 1 task in parallel...the other 4 requests, I would think, would have to wait until the custom task inside this dts package finishes. No? William Campbell "Robert Davis" <RobertDavis (AT) discussions (DOT) microsoft.com> wrote in message news 018E84F-43AA-448D-9D73-4A2CED413216 (AT) microsoft (DOT) com...You should have their synch-ups make an entry into a table. Have a job that runs every so ofter (1 minute, 5 minutes, whatever) that checks the table to see if it needs to do any cleanup. If it does, then make the top task as in process, when it's finished, mark the in-process task as complete and/or delete it. If a a task is in-process, the job would do nothing else. You need to consider what to do if a job fails and a process gets marked as in-process and stays that way. Perhaps some sort of time limit where it gets changed back to unprocessed if it's still marked in-process. Robert. "William Campbell" wrote: I have a scenario where inspector's synchronize their PDA's at the end of the day (we use SQL Server Merge Replication). When an inspector is done, I'd like to kick off a cleanup process (that code would be in a dts package). The code on the PDA, if the merge replicaton was successful, would send an http request to the same IIS that is used during Merge Replication. *The http call would have to be non-blocking (doesn't matter to the inspector if cleanup was successful, the end of their "sync" should just start the process not wait for it to finish). *For example, if 3 inspector's were sync'ing at approximately the same time, the dts package should execute it's clean-up steps one request at a time. In other words, if the dts package is executing, the other two requests should wait until the 1st one is done. Then the 3rd, should wait for the 2nd to be done. etc. Is this possible? Ideas? Thanks! |
![]() |
| Thread Tools | |
| Display Modes | |
| |