Jason

I very much apprecitae your reply.

> Sounds like you have it understood fairly well.

Maybe its a case of - the more you know the more you know you don't know
;-)

The implication of what you said is that each web action should connect and
disconnect, such that if the action has no database interaction then there
is no overhead?

I am still not sure about how to set this up.

Do I create something global in initialization - I notice in the source
there is a TIB_ConnectionPool - do I need to create this and if so how do I
get a connection from it?

Regards
Paul

>
> 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/

> >
> >
> >
>
>
>
>

___________________________________________________________________________

> 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/
>
>
>