Hi Jason

""Jason Wharton"" <jwharton@...> wrote in message
news:ap3u9g$lda$1@......

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

Some people say tax returns are simple!

I will try and explain what is puzzling me . . .

Lets say I create a web module with a session,connection and some cursors,
then in each web action I connect the connection, extract the data then
DisconnectToPool.

When the first web action is called the dll is loaded and initialized and an
instance of the web module created, the connection is made and a handle
obtained. When the action completes and DisconnectToPool is called, the
handle remains, and one connection is in the pool. I presume that since the
handle remains Interbase will still see a connection.

When a second user comes along the same web module instance will be used and
the existing handle will be reconnected then disconnected. So far this is
no different from leaving the connection connected from when the web module
is instanciated.

If another user comes along while the first web module instance is busy then
another instance is created, together with its own connection. Since there
is nothing in global memory this instance doesn't know about the first one
and in effect creates its own connection pool.

If the above assumptions are correct then the connection pool will only ever
be one handle deep and will provide no advantage over leaving the the
connection in place for the life of the module instance.

My assumptions of how the web modules are managed are based on a simple
experiment. I created an ISAPI app with a global string variable, a web
module and a private string variable. When the dll initializes an 'I' is
appended to the global variable, when the web action is called an 'A' is
added to both the global and local variables and these are returned in the
form global/local.
The first call returns IA/A, the second call IAA/AA indicating one
initialisation, two calls and two calls to the same module instance since
the local variable has not been reset between calls.
If two calls are made at the same time one returns IA/A and the other IAA/A
showing that the global area has seen two calls but the local instance
hasn't - so there must be two instances created.

I might be talking rubbish - I'd really like to know :-)

Regards
Paul

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

___________________________________________________________________________

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