Paul,

You are not talking rubbish. If the web-server's use of the DLL doesn't
allow the DLL to have its own global memory space then my pooling mechanism
will be subverted.

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:ap59op$72s$1@......

> 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