multi-threading issue - multiple simultaneous requests

Dec 7, 2007 at 1:00 AM
The session data relating to one request is getting messed up with another parallel request (happens especially when using frames).

The context objects are created for every event, so they're out of the question.
The session variables are shared across all requests within the same app, so they're no good.
Using URL is unsafe as querystring, form data, whatever, might differ per request

So how can I safely tell one request from another within an event handler? Is there a unique id anywhere, eg. in the (slow to use) server vars? Is there a better way?
Dec 7, 2007 at 2:21 AM
ps. Damn, where's my manners?! blush
Hi! And thanks for your effort in putting the library together. - Will.
Dec 7, 2007 at 10:40 PM
Edited Dec 7, 2007 at 10:41 PM

Thanks for the support, appreciated :)

The Filter.NET session instance reflects custom data that usually ISAPI Filter developers associate with TCP/IP sessions in PHTTP_FILTER_CONTEXT->pFilterContext. Normally, on PreProcHeaders event, a structure is created and set on the PHTTP_FILTER_CONTEXT->pFilterContext and this data will live while the TCP/IP session lives, and its garanteed to be used only in the http requests/responses that flow through that same TCP session.

As you know, and except on http pipelining, http request/response pairs are done sequencially inside a TCP session, so its up to the developer to manage the Filter.NET session instance data during the lifetime of the TCP session. IIS garantees this data will be related to (and only to) the TCP session while the session its established.

Normally, one would subscribe to the EndOfNetSession event, which signals the termination of the established TCP session. With this event, and with the PreProcHeaders event, its easy to know if the new request (during PreProcHeaders) is different in any sense that should trigger us to change some data in the Filter.NET session instance.

In the end, we know that the EndOfNetSession event gives us the opportunity to remove (like unmanaged data) data from the Filter.NET session instance in case we've put anything there we may need to remove.

All in all, Filter.NET does facilitate (I hope so) most development tasks done with ISAPI Filters.

Now ... back to your particular question ... You want to differentiate one request from another, so just subscribe to PreProcHeaders, since this event is hit only once on every single request. If you need to associate data to a request, then use the Filter.NET session instance and remember to clean this data on the next PreProcHeaders event (by putting some property there that tells you that you've inserted there something (a boolean?).

Let me know if this helps.
If needed, explain your scenario with detail so I can tell you the best way to use Filter.NET.

Tiago Halm