Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ISAPI multithreading explanation

455 views
Skip to first unread message

Lasse Vågsæther Karlsen

unread,
Oct 25, 1999, 3:00:00 AM10/25/99
to
I'd like to know where to find some information on ISAPI
multithreading issues, as it pertains to ISAPI dll's created with
Delphi.

In particular, I'd like to know how all this hangs together.

For instance, does the web server create several threads so that the
following happens for each thread:

1. TWebModule is instantiated (for the thread)
2. Web module processes request
3. Web module lays dormant for new request
4. Web module is unloaded

If the above matches how it works, does this mean that there is
several web modules created, or is it just the calls to the event
handlers that are threaded?

In short, I'd like to know if the components I drop into the web
module can be safely used from the event handler code or if I have to
synchronize access to them.

Any tips, links or whatever is welcome.

Nick Hodges (TeamB)

unread,
Oct 25, 1999, 3:00:00 AM10/25/99
to
On Mon, 25 Oct 1999 09:11:05 +0200, Lasse Vågsæther Karlsen
<la...@cintra.no> wrote:

>I'd like to know where to find some information on ISAPI
>multithreading issues, as it pertains to ISAPI dll's created with
>Delphi.
>
>In particular, I'd like to know how all this hangs together.
>
>For instance, does the web server create several threads so that the
>following happens for each thread:
>

By default, WebBroker-based DLL's will create a new instance in a new
thread for each request,_unless_ a cached instance is available, in
which case, it will use the cached connection. Thus, for each
request, you need to initialize your field data in the BeforeDispatch
event, as the cached connection will be used as it was left, with its
data likely in an unitialized state.


>1. TWebModule is instantiated (for the thread)
>2. Web module processes request
>3. Web module lays dormant for new request
>4. Web module is unloaded

By default, a web module will not be unloaded. However, you can
change this by setting TWebApplication.CacheConnections to False, and
by changing TWebApplication.MaxConnections

>In short, I'd like to know if the components I drop into the web
>module can be safely used from the event handler code or if I have to
>synchronize access to them.
>

The only synchronizing you need to do is to intialize your data in a
BeforeDispatch event handler for each event.


Nick Hodges
TeamB

Lasse Vågsæther Karlsen

unread,
Oct 26, 1999, 3:00:00 AM10/26/99
to
Ok, this explains a lot.

However, I have a couple of questions.

If I want a single database connection for my ISAPI dll, is this
possible, and if it is, how to set it up? As it is now, I have a
TADOConnection component in the WebModule and the way you describe it
it means that I have one such connection per cached thread.

Also, if I set MaxConnections to 1, does this in fact serialize the
code? (probably a huge performance drop on servers with traffic but
that's not the point).

Ok, last question just to see if I got this straight:

The way I understand things work is like this:

1. A number of threads are created (perhaps created when they're
needed) up to a number of MaxConnections
2. Each thread gets a separate copy of all the components I have in
the webmodule
3. The OnCreate event on the webmodule is called
4. For each request that this thread is supposed to handle, the
following happens:
a. BeforeDispatch is called
b. The appropriate WebAction event handler is called
c. AfterDispatch is called
d. The response is sent (assuming it hasn't been already)
5. When the dll is unloaded, the OnDestroy event is called

Thus, the only thing I need to guard against is simultaneous access to
files on disk and other such resources which is outside my
application.

Nick Hodges (TeamB)

unread,
Oct 27, 1999, 3:00:00 AM10/27/99
to
On Tue, 26 Oct 1999 11:03:58 +0200, Lasse Vågsæther Karlsen
<la...@cintra.no> wrote:

>If I want a single database connection for my ISAPI dll, is this
>possible, and if it is, how to set it up?

A single database connection for a web application doesn't make a lot
of sense -- by its nature a web application implies multiple sessions.
But if you must have a single session, then you can give all your
database components the same session, and then protect _all_ database
access with critical sections or a mutex.

>As it is now, I have a
>TADOConnection component in the WebModule and the way you describe it
>it means that I have one such connection per cached thread.

You actually will have multiple connections per cached thread,
assuming that each TDataset has its own Session via
TSession.AutoSessionName := True;


>Also, if I set MaxConnections to 1, does this in fact serialize the
>code? (probably a huge performance drop on servers with traffic but
>that's not the point).

No, it means that only one client can connect, and the rest are sent
away with exceptions.

\>


>The way I understand things work is like this:
>
>1. A number of threads are created (perhaps created when they're
>needed) up to a number of MaxConnections

A new thread is created everytime a cached connection is not
available.

>2. Each thread gets a separate copy of all the components I have in
>the webmodule

Yes, each instance gets its own set.

>3. The OnCreate event on the webmodule is called

Only when a new instance is created, _not_ when a cached instance is
used. If a cached instance is used, then the instance is used in the
state it was left. Hence, it is a good idea to initialize each
instance with a BeforeDispatch event handler

>4. For each request that this thread is supposed to handle, the
>following happens:
> a. BeforeDispatch is called
> b. The appropriate WebAction event handler is called
> c. AfterDispatch is called
> d. The response is sent (assuming it hasn't been already)

Switch c and d around.

>5. When the dll is unloaded, the OnDestroy event is called

Right, but the DLL will only be unloaded when the web server is shut
down.

>
>Thus, the only thing I need to guard against is simultaneous access to
>files on disk and other such resources which is outside my
>application.

You also need to protect any global variables, and any field
variables. Any non-stack-based variables are potentially a problem
and need to be protected.


Nick Hodges
TeamB

Pall Sigurdsson

unread,
Oct 29, 1999, 3:00:00 AM10/29/99
to
questions included..

In article <3816e090....@forums.borland.com>, nickh...@yahoo.com
says...


> On Tue, 26 Oct 1999 11:03:58 +0200, Lasse Vågsæther Karlsen
> <la...@cintra.no> wrote:
>
> >If I want a single database connection for my ISAPI dll, is this
> >possible, and if it is, how to set it up?
>
> A single database connection for a web application doesn't make a lot
> of sense -- by its nature a web application implies multiple sessions.
> But if you must have a single session, then you can give all your
> database components the same session, and then protect _all_ database
> access with critical sections or a mutex.
>
> >As it is now, I have a
> >TADOConnection component in the WebModule and the way you describe it
> >it means that I have one such connection per cached thread.
>
> You actually will have multiple connections per cached thread,
> assuming that each TDataset has its own Session via
> TSession.AutoSessionName := True;
>

Do you mean that you will have to get one TSession for each Query or
Stored Procedure Call or for each TDatabase? Isn't it enough to have one
TSession for each call thru the ISAPI dll. That is when the submit button
is pressed on the website at the other end.

Also does that mean if you are using BDE then BDE's internal limits about
concurrent connections and sessions will break with X-number (50?) of
concurrent connections to the ISAPI DLL?? That is if there are say three
or four database connections and each has 1 to 3 querys to the database.
(Sql 6.5 database) in the DLL.

> Nick Hodges
> TeamB
>

Pall Sigurdsson
VKS
Iceland

Nick Hodges (TeamB)

unread,
Oct 30, 1999, 3:00:00 AM10/30/99
to

>Do you mean that you will have to get one TSession for each Query or
>Stored Procedure Call or for each TDatabase? Isn't it enough to have one
>TSession for each call thru the ISAPI dll. That is when the submit button
>is pressed on the website at the other end.
>

One TSession per data module.

>Also does that mean if you are using BDE then BDE's internal limits about
>concurrent connections and sessions will break with X-number (50?) of
>concurrent connections to the ISAPI DLL?? That is if there are say three
>or four database connections and each has 1 to 3 querys to the database.
>(Sql 6.5 database) in the DLL.


You will run into any limits imposed by the BDE or your DBMS of
course. The BDE should be able to handle even the heaviest loads. AS
for your DBMS, that is dependent on your license.


Nick Hodges
TeamB

0 new messages