Separate threads in a web service after it's c

If this has been asked before my apologies, and this is .NET 2.0 ASMX Web services, again my apologies =D

A .NET Application that only exposes web services. Roughly 10 million messages per day load balanced between multiple IIS Servers. Each incoming messages is XML, and an outgoing message is XML. (XMLElement) (we have beefy servers that run on steroids).

I have a SLA that all messages are processed in under X Seconds.

One function, Linking Methods, in the process is now taking 10-20 seconds, it is required for every transaction, however is not critical that it happens before the web service returns the results. Because of this I made a suggestion to throw it on another thread, but now realize that my words and the eager developers behind them might have not fully thought this through.

The below example shows on the left the current flow. On the right what is being attempted

Effectively what I'm looking for is to have a web service spawn a long running (10-20 second) thread that will execute even after the web service is completed.

This is what, effectively, is going on:

        Thread linkThread= new Thread(delegate()
        {
            Linkmembers(GetContext(), ID1, ID2, SomeOtherThing, XMLOrSomething);
        });
        linkThread.Start();

Using this we've reduced the time from 19 seconds to 2.1 seconds on our dev boxes, which is quite substantial.

I am worried that with the amount of traffic we get, and if a vendor/outside party decides to throttle us, IIS might decide to recycle/kill those threads before they're done processing. I agree our solution might not be the "best" however we don't have the time to build in a Queue system or another Windows Service to handle this.

Is there a better way to do this? Any caveats that should be considered?

Thanks.

Apart from the issues you've described, I cannot think of any. That being said, there are ways to fix the problem that do not involve building your own solution from scratch.

Use MSMQ with WCF: Create a WCF service with an MSMQ endpoint that is IIS hosted (no need to use a windows service as long as WAS is enabled) and make calls to the service from within your ASMX service. You reap all the benefits of reliable queueing without having to build your own.

Plus, if your MSMQ service fails or throws an exception, it will reprocess automatically. If you use DTC and are hitting a database, you can even have the MSMQ transaction flow to the DB.