By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,280 Members | 2,193 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,280 IT Pros & Developers. It's quick & easy.

Store SqlConnection in SessionVariable

P: n/a
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
Nov 18 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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

Nov 18 '05 #2

P: n/a
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

Nov 18 '05 #3

P: n/a

"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
Nov 18 '05 #4

P: n/a
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
Nov 18 '05 #5

P: n/a
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

Nov 18 '05 #6

P: n/a
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

Nov 18 '05 #7

P: n/a
> 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
Nov 18 '05 #8

P: n/a
> 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
Nov 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.