Sounds like you have it understood fairly well.

Where DisconnectToPool is a benefit is you can get your connection and
dispose of it as a part of what all needs to happen in your module if at
all. If your module (request) doesn't need a connection depending on the
parameters of the request then you don't consume a connection handle at all.
This allows just a couple of handles to service the needs of more modules
than 1:1.

So, unless you are doing DisconnectToPool at a point where more work needs
to be done in the web-module and there are requests that don't even need a
connection there isn't going to be an appreciable gain because the module
would just be a 1:1 usage.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --

----- Original Message -----
From: "Paul Hope" <paulhope@...>
Newsgroups: egroups.ibobjects
To: <IBObjects@yahoogroups.com>
Sent: Monday, October 21, 2002 3:21 PM
Subject: [IBO] Still confused about ISAPI, DisconnectToPool etc


> I periodically come back to this and can't quite get a clear picture - so
> some assistance would be much appreciated :-)
>
> I'll just ramble on a bit in the hope that I raise points I might get a
> response to....
>
> Jason has provided DisconnectToPool which allows new connections to come
> from an existing pool (or makes a new one if the pool is dry) and throws
> used ones back in the pool.
>
> >From what I can gather from some experiments the initialization on the
dll
> happens only once so this is an oportunity to create some global things.
>
> In a standard ISAPI like the IBO demo, when a web action is called, an
> instance of the web unit is created (along with any IBO components placed
on
> it) - this will create a session,connection etc.
>
> If another web action follows it appears to use the same instance - so
that
> instance stays in memory until the dll is unloaded?
>
> If two or more web actions occur at the same time multiple instances of
the
> unit appear to be created and presumably stay in memory? Or maybe the
> operating system flushes them out after a time?
>
> If the connections connect when the instance of the web module is created
> then there will be as many permanent connections to the database as
> instances of the web module in memory - doesn't seem a good idea -
although
> connection overheads will be minimal.
>
> If I connect and disconnect in each action then there won't be any
permanent
> connections but the overhead will be considerable.
>
> So where does connection pooling come in? For the pool to be available
to
> any new instance of the web module it would have to be created in global
> memory. Each action would then apply for an existing connection and would
> be handed one from the pool or have one created for it. After a time
unused
> connections would be flushed out.
>
> If this is the magic of DisconnectToPool then how is the pool created and
> how do the actions obtain a connection from it? Wouldn't I need a Pool
> component that is created at initialization, and wouldn't this component
> need a GetConnection method that the actions could use?
>
> Help very much appreciated
> Regards
> Paul
>
>
>
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>