Re: Some outstanding ASP .NET questions
- From: "jehugaleahsa@xxxxxxxxx" <jehugaleahsa@xxxxxxxxx>
- Date: Thu, 24 Jan 2008 08:38:23 -0800 (PST)
On Jan 24, 8:54 am, "Scott Roberts" <srobe...@xxxxxxxxxxxxxxxxxxxxxx
software.com> wrote:
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).
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.
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.
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.
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.
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. :)
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.
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.- Hide quoted 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
.
- References:
- Some outstanding ASP .NET questions
- From: jehugaleahsa@xxxxxxxxx
- Re: Some outstanding ASP .NET questions
- From: Scott Roberts
- Some outstanding ASP .NET questions
- Prev by Date: Re: about IndexOf
- Next by Date: Re: Using LINQ to Initialise a List
- Previous by thread: Re: Some outstanding ASP .NET questions
- Next by thread: Re: Some outstanding ASP .NET questions
- Index(es):
Relevant Pages
|
