Some outstanding ASP .NET questions

[jehugaleahsa]

Hello:

We here have been working in ASP .NET for a long time now. We have
made tons of successful applications even without knowing the
specifics about the tools. However, the amount of effort it takes to
manage some application features seems way more complicated than they
should. I would like for someone to answer my questions as to how they
do something or how it is intended.

1) Whenever we log a user in, we create a database connection for that
user. Typically, we store the connection (yes, the connection) in the
Session and use a Singleton pattern to retrieve it back later:

public static OracleConnection GetConnection()
{
if (HttpContext.Current.Session["MY_CONNECTION"] == null)
HttpContext.Current.Session["MY_CONNECTION"] = new
OracleConnection("");
return
(OracleConnection)HttpContext.Current.Session["MY_CONNECTION"];
}

However, I am not sure if storing the connection in the session is a
wise idea. It works, but I am becoming wary of sticking anything in
the session. How do you handle database connections, etc. in your
ASP .NET application? Do you recreate a new connection at each
postback? for each query?

2) We noticed that TableAdapters have the ability of persisting across
postbacks. I couldn't examine the source code enough to see how it
worked. My original thought was that Microsoft stored the underlying
DataTable/DataSet in the session. However, I couldn't find it
anywhere. How does MS persist TableAdapters?

3) When navigating around a web site, we typically store table key
information in the session so that we can query information off those
keys. Is it appropriate to store table key information in the session?
You see, I come from the days of POST, hidden fields, etc. I feel
weird putting information in the session like that. But, then again,
what would the session be for?

4) ASP .NET Object Data Sources allow the select command to get its
parameters from many places. However, we here typically have a class
or two that manage our session variables. Similar to the GetConnection
example above, we have a bunch of static methods that retrieve the
session and do our type handling. It is a lot more safe that way.
However, ObjectDataSources don't allow us to get parameter information
from an object or class. Is there a better way of passing parameter
information to an ObjectDataSource?

5) MultiViews can be very useful. But at the same time, they cause
serious issues once the page size gets large enough. We have an
application where modifying the interface is a 15 minute task. We
realized the problem is due to paging and VS storing undo/redo
actions; this causes OutOfMemoryExceptions a lot. Is ASP .NET better
geared toward single page applications with one big MultiView or many
pages linked with session variables? or is there a better way to pass
information around?

6) For some reason, prior to authentication/authorization, the session
dictionary appears to be null occasionally. We have never been able to
figure it out. In some application, the session always exists, but for
some reason, it becomes null in other applications. We are not sure
what causes it. However, we have noticed that it doesn't happen once
the user is logged in. The question is, is there a new session created
once a user logs in? is there a session at all prior to log in?

We need to know because our membership and role provider classes both
need database connections. Where is the best place to store a
connection for a provider class? should we be storing connections at
all? I was thinking in the Application dictionary, since it belongs to
all users.

--

I think that will do for now. Thank you for filling in any of the
holes.

Thanks,
Travis

 

[Scott Roberts]

I can't answer all of your questions, but I'll tell you what has worked for
us.

1) Whenever we log a user in, we create a database connection for that
user. Typically, we store the connection (yes, the connection) in the
Session and use a Singleton pattern to retrieve it back later:

public static OracleConnection GetConnection()
{
if (HttpContext.Current.Session["MY_CONNECTION"] == null)
HttpContext.Current.Session["MY_CONNECTION"] = new
OracleConnection("");
return
(OracleConnection)HttpContext.Current.Session["MY_CONNECTION"];
}

However, I am not sure if storing the connection in the session is a
wise idea. It works, but I am becoming wary of sticking anything in
the session. How do you handle database connections, etc. in your
ASP .NET application? Do you recreate a new connection at each
postback? for each query?

We create a new connection for every single query. Given that the built-in
..Net connection objects handle connection pooling automatically, there's
really no reason to re-use connection objects. I assume your
OracleConnection class handles connection pooling as well, but it'd be a
good idea to verify it before making a change.

3) When navigating around a web site, we typically store table key
information in the session so that we can query information off those
keys. Is it appropriate to store table key information in the session?
You see, I come from the days of POST, hidden fields, etc. I feel
weird putting information in the session like that. But, then again,
what would the session be for?

Not sure exactly what you mean, but I can say that we generally use GUIDs
for primary keys and pass the GUID in the URL.

5) MultiViews can be very useful. But at the same time, they cause
serious issues once the page size gets large enough. We have an
application where modifying the interface is a 15 minute task. We
realized the problem is due to paging and VS storing undo/redo
actions; this causes OutOfMemoryExceptions a lot. Is ASP .NET better
geared toward single page applications with one big MultiView or many
pages linked with session variables? or is there a better way to pass
information around?

I'm not sure about MultiViews in particular, but we tend to create a new
page for each logical function. If a page is "too large", we then create
User Controls for each logical "piece" of the page. User Controls are then
loaded dynamically into the page on a "as needed" basis at run-time.

6) For some reason, prior to authentication/authorization, the session
dictionary appears to be null occasionally. We have never been able to
figure it out. In some application, the session always exists, but for
some reason, it becomes null in other applications. We are not sure
what causes it. However, we have noticed that it doesn't happen once
the user is logged in. The question is, is there a new session created
once a user logs in? is there a session at all prior to log in?

Sessions are useful, but somewhat unreliable - depending on your
environment. If you are on a shared host, I would avoid using sessions as
much as possible. If you are on a dedicated server, you have more control
over the things that cause session resets. Even so, I'd avoid going "session
crazy" and just putting everything in there. Everything in moderation.

We need to know because our membership and role provider classes both
need database connections. Where is the best place to store a
connection for a provider class? should we be storing connections at
all? I was thinking in the Application dictionary, since it belongs to
all users.

As mentioned previously, if your DB classes support connection pooling then
you shouldn't be re-using connections, and this problem is resolved.

 

[jehugaleahsa]

I can't answer all of your questions, but I'll tell you what has worked for
us.

1) Whenever we log a user in, we create a database connection for that
user. Typically, we store the connection (yes, the connection) in the
Session and use a Singleton pattern to retrieve it back later:

public static OracleConnection GetConnection()
{
   if (HttpContext.Current.Session["MY_CONNECTION"] == null)
       HttpContext.Current.Session["MY_CONNECTION"] = new
OracleConnection("");
   return
(OracleConnection)HttpContext.Current.Session["MY_CONNECTION"];
}

However, I am not sure if storing the connection in the session is a
wise idea. It works, but I am becoming wary of sticking anything in
the session. How do you handle database connections, etc. in your
ASP .NET application? Do you recreate a new connection at each
postback? for each query?

We create a new connection for every single query. Given that the built-in
.Net connection objects handle connection pooling automatically, there's
really no reason to re-use connection objects. I assume your
OracleConnection class handles connection pooling as well, but it'd be a
good idea to verify it before making a change.

That is good to know. I think we can easily accomidate that since we
are using a Singletons (thank goodness).

Not sure exactly what you mean, but I can say that we generally use GUIDs
for primary keys and pass the GUID in the URL.

I was referring to primary keys in database tables. We tend to have
heirarchical data, so we tend to pass a lot of keys around. If you use
GUIDs for your primary keys, then we are talking about the same thing.
I am always wary of using query strings (GET) for passing data around.
Perhaps I am just paranoid, but I am always afraid a user will copy
and paste a query string and it will cause my application to behave
funny.

I'm not sure about MultiViews in particular, but we tend to create a new
page for each logical function. If a page is "too large", we then create
User Controls for each logical "piece" of the page. User Controls are then
loaded dynamically into the page on a "as needed" basis at run-time.

I have attempted this. It does work. I tell my coworkers to avoid
MultiViews if possible; the application I was referring to is so
dependent on MultiView now, that it would be a major retool to
seperate out the functionality (it was also my first ASP .NET
application). I will hold to my original position, then, and use
MultiView sparingly.

Sessions are useful, but somewhat unreliable - depending on your
environment. If you are on a shared host, I would avoid using sessions as
much as possible. If you are on a dedicated server, you have more control
over the things that cause session resets. Even so, I'd avoid going "session
crazy" and just putting everything in there. Everything in moderation.

Looking back on my past projects, I realized the massive amount of
session I used. I used to store entire DataTables in memory and I just
requeried anyway! Recently I started to wonder whether I was using
session correctly at all. That is when I got on this "we don't need no
stinking session" kick. Thank goodness we have a small user base.
Perhaps I should start creating load tests.

As mentioned previously, if your DB classes support connection pooling then
you shouldn't be re-using connections, and this problem is resolved.- Hidequoted text -

- Show quoted text -

I will let my coworkers know. I have already found a lot of sites
agreeing with what you are saying. And connection time is minimal, so
it doesn't really buy us much to keep a connection around.

Thanks,
Travis

 

[jehugaleahsa]

Hello:

We here have been working in ASP .NET for a long time now. We have
made tons of successful applications even without knowing the
specifics about the tools. However, the amount of effort it takes to
manage some application features seems way more complicated than they
should. I would like for someone to answer my questions as to how they
do something or how it is intended.

1) Whenever we log a user in, we create a database connection for that
user. Typically, we store the connection (yes, the connection) in the
Session and use a Singleton pattern to retrieve it back later:

public static OracleConnection GetConnection()
{
    if (HttpContext.Current.Session["MY_CONNECTION"] == null)
        HttpContext.Current.Session["MY_CONNECTION"] = new
OracleConnection("");
    return
(OracleConnection)HttpContext.Current.Session["MY_CONNECTION"];

}

However, I am not sure if storing the connection in the session is a
wise idea. It works, but I am becoming wary of sticking anything in
the session. How do you handle database connections, etc. in your
ASP .NET application? Do you recreate a new connection at each
postback? for each query?

2) We noticed that TableAdapters have the ability of persisting across
postbacks. I couldn't examine the source code enough to see how it
worked. My original thought was that Microsoft stored the underlying
DataTable/DataSet in the session. However, I couldn't find it
anywhere. How does MS persist TableAdapters?

3) When navigating around a web site, we typically store table key
information in the session so that we can query information off those
keys. Is it appropriate to store table key information in the session?
You see, I come from the days of POST, hidden fields, etc. I feel
weird putting information in the session like that. But, then again,
what would the session be for?

4) ASP .NET Object Data Sources allow the select command to get its
parameters from many places. However, we here typically have a class
or two that manage our session variables. Similar to the GetConnection
example above, we have a bunch of static methods that retrieve the
session and do our type handling. It is a lot more safe that way.
However, ObjectDataSources don't allow us to get parameter information
from an object or class. Is there a better way of passing parameter
information to an ObjectDataSource?

5) MultiViews can be very useful. But at the same time, they cause
serious issues once the page size gets large enough. We have an
application where modifying the interface is a 15 minute task. We
realized the problem is due to paging and VS storing undo/redo
actions; this causes OutOfMemoryExceptions a lot. Is ASP .NET better
geared toward single page applications with one big MultiView or many
pages linked with session variables? or is there a better way to pass
information around?

6) For some reason, prior to authentication/authorization, the session
dictionary appears to be null occasionally. We have never been able to
figure it out. In some application, the session always exists, but for
some reason, it becomes null in other applications. We are not sure
what causes it. However, we have noticed that it doesn't happen once
the user is logged in. The question is, is there a new session created
once a user logs in? is there a session at all prior to log in?

We need to know because our membership and role provider classes both
need database connections. Where is the best place to store a
connection for a provider class? should we be storing connections at
all? I was thinking in the Application dictionary, since it belongs to
all users.

--

I think that will do for now. Thank you for filling in any of the
holes.

Thanks,
Travis

Anyone got anything for my second and forth question?

 

[Arne Vajhøj]

1) Whenever we log a user in, we create a database connection for that
user. Typically, we store the connection (yes, the connection) in the
Session and use a Singleton pattern to retrieve it back later:

public static OracleConnection GetConnection()
{
if (HttpContext.Current.Session["MY_CONNECTION"] == null)
HttpContext.Current.Session["MY_CONNECTION"] = new
OracleConnection("");
return
(OracleConnection)HttpContext.Current.Session["MY_CONNECTION"];
}

However, I am not sure if storing the connection in the session is a
wise idea. It works, but I am becoming wary of sticking anything in
the session. How do you handle database connections, etc. in your
ASP .NET application? Do you recreate a new connection at each
postback? for each query?

You way scale very badly and does not improve performance (because .NET
uses connection pooling).

Open just before you need the connection and close as soon as your are
done using it.

2) We noticed that TableAdapters have the ability of persisting across
postbacks. I couldn't examine the source code enough to see how it
worked. My original thought was that Microsoft stored the underlying
DataTable/DataSet in the session. However, I couldn't find it
anywhere. How does MS persist TableAdapters?

I would not expect any type to be "magically" saved between requests.

Can you illustrate with an example what you are observing ?

3) When navigating around a web site, we typically store table key
information in the session so that we can query information off those
keys. Is it appropriate to store table key information in the session?
You see, I come from the days of POST, hidden fields, etc. I feel
weird putting information in the session like that. But, then again,
what would the session be for?

If it really is session wide information, then using session should
be fine.

Arne

 

[jehugaleahsa]

1) Whenever we log a user in, we create a database connection for that
user. Typically, we store the connection (yes, the connection) in the
Session and use a Singleton pattern to retrieve it back later:

public static OracleConnection GetConnection()
{
    if (HttpContext.Current.Session["MY_CONNECTION"] == null)
        HttpContext.Current.Session["MY_CONNECTION"] = new
OracleConnection("");
    return
(OracleConnection)HttpContext.Current.Session["MY_CONNECTION"];
}

However, I am not sure if storing the connection in the session is a
wise idea. It works, but I am becoming wary of sticking anything in
the session. How do you handle database connections, etc. in your
ASP .NET application? Do you recreate a new connection at each
postback? for each query?

You way scale very badly and does not improve performance (because .NET
uses connection pooling).

Open just before you need the connection and close as soon as your are
done using it.

2) We noticed that TableAdapters have the ability of persisting across
postbacks. I couldn't examine the source code enough to see how it
worked. My original thought was that Microsoft stored the underlying
DataTable/DataSet in the session. However, I couldn't find it
anywhere. How does MS persist TableAdapters?

I would not expect any type to be "magically" saved between requests.

Can you illustrate with an example what you are observing ?

My question is how DataTables are stored across post backs, that's
all. I cannot see them in the session, so they must be being stored
else-where. Unless they are being regenerated each and every time.
However, I have trouble understanding the point in DataTables if they
must be regenerated every time. Am I making any sense?