Subject Re: [IBO] Still confused about ISAPI, DisconnectToPool etc
Author Jason Wharton
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

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

----- Original Message -----
From: "Paul Hope" <paulhope@...>
Newsgroups: egroups.ibobjects
To: <>
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
> 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
> it) - this will create a session,connection etc.
> If another web action follows it appears to use the same instance - so
> instance stays in memory until the dll is unloaded?
> If two or more web actions occur at the same time multiple instances of
> 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 -
> connection overheads will be minimal.
> If I connect and disconnect in each action then there won't be any
> connections but the overhead will be considerable.
> So where does connection pooling come in? For the pool to be available
> 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
> 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
> without the need for BDE, ODBC or any other layer.
> - your IBO community resource for Tech Info
> keyword-searchable FAQ, community code contributions and more !
> Your use of Yahoo! Groups is subject to