The only thing you need to do is use the connection handle when necessary
and return it to the pool as soon as possible. IBO takes care of the rest.
You may want to from time to time have it flush the handles out of the pool
but that's it.

You people really have a hard time with things made as simple as possible
don't you? <g>

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

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


"Paul Hope" <paulhope@...> wrote in message
news:ap3qh8$ju8$1@......

> 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