Store SqlConnection in SessionVariable

[Rolf Gossen]

Hello NG,

sometimes I read: "Never store an SqlClient.SqlConnection in a Session
Variable." But noone explains why. Is there anyone who can briefly
summarize the main problems about this approach.

Thanks in advance
Rolf

[Andrew Banks]

Can't sessions be hijacked and therefore a user could potentially have
access to this data?

"Rolf Gossen" <ro*********@gmx.de> wrote in message
news:d3*************************@posting.google.co m...

Hello NG,

sometimes I read: "Never store an SqlClient.SqlConnection in a Session
Variable." But noone explains why. Is there anyone who can briefly
summarize the main problems about this approach.

Thanks in advance
Rolf

[Patrice]

It forces each user to work its own connection. Instead the recommended
approach is AFAIK still to "create" a connection at the beginning of each
page and to release it after...

With the pooling feature provided by ADO.NET, when you "create" a connection
it is actually taken from a pool and returned to this pool when you
"destroy" it. With this approach "creating" a new connection is quick (as it
is actually taken from a pool) and x users can be serviced using a much
lower number of connections (as each user will "borrow" a connection from
the pool just during the period it really needs one).

Patrice

"Rolf Gossen" <ro*********@gmx.de> a écrit dans le message de
news:d3*************************@posting.google.co m...

Hello NG,

sometimes I read: "Never store an SqlClient.SqlConnection in a Session
Variable." But noone explains why. Is there anyone who can briefly
summarize the main problems about this approach.

Thanks in advance
Rolf

[Hans Kesting]

"Rolf Gossen" <ro*********@gmx.de> wrote in message news:d3*************************@posting.google.co m...

Hello NG,

sometimes I read: "Never store an SqlClient.SqlConnection in a Session
Variable." But noone explains why. Is there anyone who can briefly
summarize the main problems about this approach.

Thanks in advance
Rolf

If you store opened connections, then you might run out of connections
when the site is moderately busy.
If you close the connection as soon as possible, then the built-in
connection pooling will prevent this problem. Also the pooling
makes sure that new connections are made quickly, so there is
(almost?) no penalty in closing the connection.

In the COM+/ASP world there were even bigger problems with storing
(COM/COM+) objects in the session.
Hans Kesting

[Cor Ligthert]

Hi Rolf,

I don't know however is it not store in a viewstate, because that can easyly
be hacked.
However a session stays on the server in my opinion.

I assume you are talking about a connectionstring?

If I am wrong in this feel free to correct me?
Cor

[Lostinet]

Hi . You should not do this !

a SqlConnection is a expansive object .
so you must release it when you dont need it .
and you should not make a SqlConnection for each Session . (That means the
SqlConnection is not shared)

You can choose my component to manage SqlConnection
:
Lostinet.Data.SqlScope

download it : http://www.lostinet.com/

--
Thanks.

Lostinet (MS ASP.NET MVP)
lo*********@hotmail.com
---------------------------
Need MessageBox,ComboBox,DatePicker,PasswordBox,TreeVie w,ASP.Net RPC ?
http://www.lostinet.com/
"Rolf Gossen" <ro*********@gmx.de> ????
news:d3*************************@posting.google.co m...

Hello NG,

sometimes I read: "Never store an SqlClient.SqlConnection in a Session
Variable." But noone explains why. Is there anyone who can briefly
summarize the main problems about this approach.

Thanks in advance
Rolf

[Raymond Lewallen]

Rolf,

I think the more obvious question for you is, why are you creating sql
connections for somewhere where you also have access to the session class?
Connections should be handled in a seperate layer/assembly, such as a data
access layer or a business logic layer, not in the presentation layer.

Raymond Lewallen

"Rolf Gossen" <ro*********@gmx.de> wrote in message
news:d3*************************@posting.google.co m...

Hello NG,

sometimes I read: "Never store an SqlClient.SqlConnection in a Session
Variable." But noone explains why. Is there anyone who can briefly
summarize the main problems about this approach.

Thanks in advance
Rolf

[Rolf Gossen]

> If you store opened connections, then you might run out of connections

when the site is moderately busy.
If you close the connection as soon as possible, then the built-in
connection pooling will prevent this problem. Also the pooling
makes sure that new connections are made quickly, so there is
(almost?) no penalty in closing the connection.

I think this is quiet a convincing argument!
Thank you.
Rolf

[Rolf Gossen]

> I think the more obvious question for you is, why are you creating sql

connections for somewhere where you also have access to the session class?
Connections should be handled in a seperate layer/assembly, such as a data
access layer or a business logic layer, not in the presentation layer.

Hello Raymond,

This is an interesting aspect, too, though I must confess, that this
was not my original question.
Thank you
Rolf