Thank you Helen, I undestand how ISAPI works, my doubt, probably for
my broken english, is when IBO says "all data access components for
that session must reside on that single module".


I am not clear, does it mean that I cannot use data access components
in other modules? Do I need to put a TIB_Session in each data module?

By the way, so you know some web where I can find an example ISAPI-IBO?


Thank you

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> 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
>