Opening/closing db connection in global.asax

is it a good or bad practise to use the session_start & session_end for
opening & closing the database connection? I'd thought that on powerful
servers today the time the connection is kept locked should not matter as
scripts (especially .Net!) are now run in milliseconds?On Tue, 15 Mar 2005 14:06:08 -0600, Daves <dbspam@.simnet.is> wrote:

> is it a good or bad practise to use the session_start & session_end for
> opening & closing the database connection? I'd thought that on powerful
> servers today the time the connection is kept locked should not matter as
> scripts (especially .Net!) are now run in milliseconds?
>
Bad practice; as discovered elsewhere, these 2 events don't always occur
or if they do, and your session is 20 minutes, then if a user closes their
browser, the connection sits there (open) for another 19+ minutes.
ADO.NET will pool connections for you automatically, so there's no need to
do anything other than open a connection when needed and close as soon as
done.
There are some caveats to consider, though, as illustrated in this article:
http://www.ondotnet.com/pub/a/dotne...9/connpool.html
Craig Deelsnyder
Microsoft MVP - ASP/ASP.NET
Actually, if the connection pooling is turned on, it does not even matter
where the connections are being opened -- since the connections are re-used.
For a good design, create a class that dispenses Connection objects, and you
can use this from anywhere.
public class ConnectionDispenser
{
// Get a new connection object
public SqlConnection GetConnection()
{
}
}
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Daves" <dbspam@.simnet.is> wrote in message
news:uQS8moZKFHA.1176@.TK2MSFTNGP12.phx.gbl...
> is it a good or bad practise to use the session_start & session_end for
> opening & closing the database connection? I'd thought that on powerful
> servers today the time the connection is kept locked should not matter as
> scripts (especially .Net!) are now run in milliseconds?
>
I'd discourage this approach as it's unnecessary to keep this resource open
when most of the time you're not using it. In general you should open the
connection when you need it, use it, then close it as soon as possible. By
default (if you're using the SqlServer managed provider) connections are
pooled, so if other requests into your application are connecting to the
DB with the same connection string (same credentials, essentially) then they
piggy-back off of the open connection. Makes for better sharing of the resou
rce
(connection).
-Brock
DevelopMentor
http://staff.develop.com/ballen

> is it a good or bad practise to use the session_start & session_end
> for opening & closing the database connection? I'd thought that on
> powerful servers today the time the connection is kept locked should
> not matter as scripts (especially .Net!) are now run in milliseconds?
>
The best approach is using MS/DAAB. It manages connection for you
efficiently and bug free.
John
"Daves" <dbspam@.simnet.is> wrote in message
news:uQS8moZKFHA.1176@.TK2MSFTNGP12.phx.gbl...
> is it a good or bad practise to use the session_start & session_end for
> opening & closing the database connection? I'd thought that on powerful
> servers today the time the connection is kept locked should not matter as
> scripts (especially .Net!) are now run in milliseconds?
>
well the main idea is to make code shorter, it's "noisy" to have all these
open/close lines repeatedly!!
Do you know of any article on this subject? (c#)
"Manohar Kamath" <mkamath@.TAKETHISOUTkamath.com> wrote in message
news:%232Jw0tZKFHA.3332@.TK2MSFTNGP15.phx.gbl...
> Actually, if the connection pooling is turned on, it does not even matter
> where the connections are being opened -- since the connections are
> re-used.
> For a good design, create a class that dispenses Connection objects, and
> you
> can use this from anywhere.
> public class ConnectionDispenser
> {
> // Get a new connection object
> public SqlConnection GetConnection()
> {
> }
> }
> --
> Manohar Kamath
> Editor, .netWire
> www.dotnetwire.com
>
> "Daves" <dbspam@.simnet.is> wrote in message
> news:uQS8moZKFHA.1176@.TK2MSFTNGP12.phx.gbl...
>