Store SqlConnection in SessionVariable

R

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
 
A

Andrew Banks

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

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
 
H

Hans Kesting

Rolf Gossen said:
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
 
C

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
 
L

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/
 
R

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
 
R

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
 
R

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top