At 10:22 PM 26/03/2007, you wrote:

>In the Ibobjects documentation related with IBobject and ISAPI, I can
>read "You CAN use ISAPI if you take a few precautions. The first
>requirement is that you must put a TIB_Session component on the
>datamodule and set it first in the creation order. Then, all data
>access components for that session must reside on that single module."
>
>
>Which is the reason?

The short answer is, if you mix ownership and dependency across
session boundaries, you will corrupt memory on the server and crash
your application, if not the entire server.

>In my case, I use several data modules in the
>same application. How can I avoid this problem?

It's not a "problem" that's looking for an "avoidance tactic". It's
just the nature of the ISAPI beast. ISAPI instances are created by
Windows IIS as threads of the IS process. One instance of an ISAPI
module has to be entirely self-contained, since IIS has no knowledge
of what your application is doing and your application has no
knowledge of what IIS or users are doing.

The IB_Session component is the "outer wrapper" for one
instance. When your typical Internet user wanders off in the middle
of a session, IIS will eventually realise he has gone and instruct
the module instance to destroy itself.

If you are using multiple data modules, you'll have to make certain
that they are created and destroyed in strict order/reverse order,
respectively, beginning and ending with the IB_Session, respectively,
and that there is at most one connection per database during the life
of a module instance.

Helen