This is not that future post but I'm going to set some background for that issue first.
Prior to ColdFusion MX, developers didn't have to think much about multithreaded execution of their code: they locked all shared scope access and that was it. With CFMX, or at least with CFMX 6.1, developers now had to face the issue of thread safety far more directly if they were writing CFCs: if you forget to var declare a local variable and that CFC is stored in a shared scope, you could get some very unpredictable results under load because multiple requests would overwrite your shared scope data. Much has been written about the necessity of vardeclaring all your local variables so I'm not going to belabor that point.
Now CFMX 7 brings the ability to write code that executes in response to events and protocols other than HTTP requests. It has an explicit event queue and an explicit thread pool. The CFCs you write for event gateways can be executed by many requests at once so if you use shared scopes, you need to exercise the same level of care about var declaring all local variables.
Using the asynchronous CFML gateway is very easy: store your parameters in a struct, call sendGatewayMessage() and off it goes, to be executed in parallel, while your code continues on.
Your event gateways can be set to start up automatically when CFMX starts up, or they can be set to require manual startup. I'm going to write a blog entry shortly that should help you decide which is the best choice for a given event gateway.
The other thing to consider is how much parallelism you need. Bear in mind that each event gateway thread is effectively a simultaneous request for CFMX to execute and, for performance reasons, you'll see that the number of simultaneous requests that CFMX can handle should be limited so that the server is not overwhelmed (3-5 per CPU is the rough guide). I'm going to write a blog entry about how this concern also applies to the event gateways.
We have also found that using var in local CFC functions has helped with execution time. We have some intensive processes and have worked out squeezing out every little millisecond and found that when we put in some var declarations in some functions where they were missing it shaved some time off total processing. Just another great reason to use those vars!
Paul
