OOpse...I meant to say that the valueUnbound method of your object will be
called...there you can close the connection...
Mike
----- Original Message -----
From: "Michael P. McCutcheon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 05, 2001 6:50 PM
Subject: Re: Speeding up database accesses
> You should never rely on garbage collection to handle your connections.
> Just use the HTTPSessionBindingListener interface, and call the
valueUnbound
> when the session exipres...there you can cleanly close the connection.
>
> Mike
>
>
> ----- Original Message -----
> From: "Randy Layman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, February 05, 2001 1:13 PM
> Subject: RE: Speeding up database accesses
>
>
> >
> > I hate it when other people beat me to the responses....
> >
> > Basically, yes. Another reason is that some of the JDBC drivers
> > taht I have worked with don't behave properly when garbage collected.
> > Therefore, when the session dies, the Connection would die a
> > garbage-collected death, sometimes leaving hanging connections.
> >
> > Yet another reason is when trying to deal with the JDBC-ODBC bridge
> > and their problem of not handling concurrent connections. One
connection
> > per session makes it very difficult to limit the access. Its much
easier
> > where there is one class handling the the database traffic to implement
> this
> > kind of traffic cop approach, or caching, etc.
> >
> > Lastly, it generally breaks the Model/View/Controller design
> > philisophy to include the model (database) with the view (jsp) in the
same
> > class.
> >
> > Randy
> >
> >
> > -----Original Message-----
> > From: Steve Ruby [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, February 05, 2001 4:42 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Speeding up database accesses
> >
> >
> >
> >
> > For one reason you are going to have a connection dedicated
> > to that session even if it isn't using it, so you will
> > have one connection per session when you really only need
> > one connection per use which is likely to be MUCH smaller, especially
> > considering the session doesn't die until session-timeout so you
> > will have a buch of lame connection sitting around takeing up
> > memory waiting to die..
> >
> > A pool (especially a good one) will allow you to have
> > only the number of connections you need available to you
> > at any time.
> >
> >
> >
> > CPC Livelink Admin wrote:
> > >
> > > Why is it a bad idea to use a session variable?
> > >
> > > -----Original Message-----
> > > From: Randy Layman [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, February 05, 2001 3:52 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Speeding up database accesses
> > >
> > > One possibility (altough a bad idea) is to stick it into your
> > > session.
> > >
> > > Another possibility is to create an object that has a static
> > > variable for the Connection. Then provide methods to access it.
> Remember
> > > that you need to make sure only one thing at a time is using the
> > connection.
> > >
> > > There are some pooling connection managers out there already.
> One
> > > that I know of off the top of my head is PoolMan. You can go over to
> > > sourceforge.net and search for it.
> > >
> > > Randy
> > >
> > > -----Original Message-----
> > > From: John Coonrod [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, February 05, 2001 4:19 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Speeding up database accesses
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
