Session and Database Connection, Which Is More Costy?

[gnewsgroup]

I am just curious about this issue.

I have a few buttons on a single aspx page. Each time one of the
buttons is clicked, I need to know if a customer has an unpaid
balance.

I only know of 2 ways to handle this:

1. Open the database connection only when the page is loaded the first
time, check the database for unpaid balance and save it as a session
variable. (Thus avoiding repetitive db connections.)

2. Upon clicking of each button on the page, I open up the database
and check the database for unpaid balance. (Thus avoiding session
variables.)

I heard through the grapevine that database connection is costy. In
the same manner, I heard that session will cause a scalability
problem.

So, in situations like this, what factors help us decide which
strategy to use?

Also, how about saving the value in a hidden field?

 

[Jonathan Wood]

For small amounts of data, I would say Session in your best bet. Session
data is in memory so is much more efficent. Database should be used for
larger amounts of data and of course data that needs to be saved between
sessions.

 

[gnewsgroup]

For small amounts of data, I would say Session in your best bet. Session
data is in memory so is much more efficent. Database should be used for
larger amounts of data and of course data that needs to be saved between
sessions.

That makes perfect sense. How about storing the value in a hidden
field?

 

[sloan]

You don't need to fear the Session variable, you just need to use it
frugally.

But a simple yes/no for 1 person...on a single aspx page. Use the Session
after you get it from the database the first time.

The problem with Session is when people start using it to hold 100,00
records in a DataSet, and you got 1,000 users. Then it isn't so frugal
anymore.

You can use a hidden field as well. Its your option.

 

[bruce barker]

i check session first, if not there do query and save to session. this
handles never clicking button, and session recycles

-- bruce (sqlwork.com)

 

[gnewsgroup]

i check session first, if not there do query and save to session. this
handles never clicking button, and session recycles

-- bruce (sqlwork.com)

OK, great, but I find session sorta messy though. For example, if
somewhere in your logic you forget to update the session variable
value, you will be using the same old value, and you may not know that
something is wrong.

 

[sloan]

You can write static methods (shared vb.net) to encapsulate the class.


public class HelperSessionInfo
{

private readonly string USER_ID_KEY = "UserIdKey";

public static void SetUserID (int userId)
{
Session[USER_ID_KEY] = userId;
}

public static int GetUserId()
{
int returnValue = 0;
if(null!=Session[USER_ID_KEY]
{
returnValue = (int)Session[USER_ID_KEY];
}

return returnValue;
}


}



That's a tad bit cleaner.

You can check this out as well.
http://sholliday.spaces.live.com/blog/cns!A68482B9628A842A!151.entry

it will actually give you strong typing.
and good ".Clear()" and ".Remove(key)" methods.


...

 

[Ian Semmel]

Is there some tool which enables you to check the size/contents of the
session ?

 

[Roland Dick]

Hi gnewsgroup,

other than the other posters, I would not automatically recommend a
session variable or hidden field. The reason is that during your session
lifecycle, the data in the database can be changed by another user, and
then you end up returning old data to your user (it could be days old
data, if the user keeps interacting with the site so the session doesn't
time out!)

I am not sure what your DB query looks like and how many records you
have to query against, but checking for unpaid balance (view?) shouldn't
be all that time consuming on the DB side, and I doubt it will have a
major impact on the ASP.NET side.

Just my 2c,

Roland