Timers in ISAPI's

1. ISAPI is a DLL running in the context of IIS. IIS creates a new thread
for each request, so you must write the app as a multi threading
application. If you use the BDE, this means you have to start a new session
for each request. If there is common data for all requests, or common
objects, you'll have to synchronize access to those items (e.g. with
critical sections).

2. The IIS thread has no message queue, so you can't use functions that
operate on window handles. Specifically, you can't use the SetTimer API
routine, and consequenly you can't use the TTimer component. It took me a
long time to find out. You can simulate a timer by starting a new thread,
suspending it and waiting for it with a time out.

3. The standard ISAPI components create instances of a TWebModule class, but
never remove them. The idea is to reuse TWebModule instance after they have
completed their work. However, if you open datasets in it, those datasets
will remain open until the IIS is terminated, which doesn't make sense of
course. So it is advisable to close any BDE session, or any other dataset
component you opened for handling a request, after you have completed the
request. Otherwise your database will remain in use forever and you'd have
to shutdown the entire IIS if you want to perform an upgrade of the
database.

4. There is no way to shutdown an ISAPI DLL without shutting down the entire
IIS. There is a nice workaround for this by William Egge, see
http://www.eggcentric.com/ISAPILoader.htm.

5. You can debug the ISAPI DLL by using the IIS as host application for the
app. See the Delphi documentation. It is easier, however to create a
debugging aid app, that loads your DLL and generates the exact requests at
your demand.

6. The best way to check if the HTML code generated by your ISAPI is valid,
is to validate it with the HTML validator of W3C, found at
http://validator.w3.org/. This is better than using your browser to test the
code, because your code might fail with a different browser. If the on line
validator says the code is OK, that it is ok.

7. Don't put your ISAPI DLL in the default Scripts directory, but give it a
directory of its own. This makes setting up IIS security much easier.

8. Don't use IIS for debugging the ISAPI DLL, but rather use Personal Web
Server on a W95/98 machine, or a host app you created yourself. This
involves much less security issues and security is a real pain in the but
with ISAPI. If you don't have to bother about security in the first place,
it's easier to concentrate on the actual functionality.

9. If your application doesn't have to serve high traffic, use CGI in stead
of ISAPI. This is much easier to create and for most application it works
fine. Only if you expect many requests per second, you'll need the better
performance of ISAPI.

Enjoy!

Peter Laman
Lance IT B.V. Roermond, the Netherlands
Developers of Protecs Safety Management for the Chemical Industry.
drs. Peter Laman,
Senior Software Engineer.