Using Session object to store dataset

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a datagrid which enables paging and the data is displayed in it when
user selects an item from a drop down list.

The code for populating data into the Datagrid is contained in the
DropDownList1_SelectedIndexChanged event handler. The Datagrid can only
display 10 rows at a time. When user clicks on a new Page number, no new rows
are displayed except when a new item is selected from the dropdown list then
would the next few rows be displayed.

Paging only works if Session object is used to store and retrieve the
dataset. The following is contained in the "DataGrid1_PageIndexChanged" Event
Handler.

Datagrid1.DataSource = CType(Session("ds"), Dataset)
Datagrid1.DataMember = "DataTable"
Datagrid1.DataBind( )
___________________________________
I just want to understand the reason behind this function although the
desired result has been achieved.

Why didn't the datagrid display the next few rows of data if Session object
is not used. Isn't the dataset stored in the memory and once called for by
the Datagrid1_PageIndexChanged event handler, data would be immediately
retrieved from there ?
 
Kim,

No a webpage is stateless.

The only reasonable way to save data from a client between posts is in a
session or a viewstate.

I hope this helps,

Cor
 
Generally speaking, storing data source in Session can improve performance.
However, in some situation it causes problem. For example, in a user
intensive application, more than hundreds users access the page in the same
time. If you store large data, e.g. dataset or datatable in Session, it will
cause out of memory problem. Hence, in that case you might select other
options such as storing data in ViewState, or re-querying data from backend
database.

HTH

Elton Wang
 
Yup, Session or ViewState but...

.... storing a DataSet in ViewState 'usually' is not the best idea as that
data makes a round trip to and from the user's browser. I consider
ViewState a good place to persist small amounts of data, ID's, etc.

A DataSet isn't the lightest weight object in town, so Session is usually a
good place to persist that state.

HTH,
geo
 
Elton,
Generally speaking, storing data source in Session can improve
performance.
However, in some situation it causes problem. For example, in a user
intensive application, more than hundreds users access the page in the
same
time. If you store large data, e.g. dataset or datatable in Session, it
will
cause out of memory problem. Hence, in that case you might select other
options such as storing data in ViewState, or re-querying data from
backend
database.
Click to expand...
In the last solution the data can be changed by another user while you don't
have any control about that, therefore in my opinion in general a bad
solution.

If it is about very static data, than there are some other solutions as
well.

Just my idea

Cor
 
¤ I have a datagrid which enables paging and the data is displayed in it when
¤ user selects an item from a drop down list.
¤
¤ The code for populating data into the Datagrid is contained in the
¤ DropDownList1_SelectedIndexChanged event handler. The Datagrid can only
¤ display 10 rows at a time. When user clicks on a new Page number, no new rows
¤ are displayed except when a new item is selected from the dropdown list then
¤ would the next few rows be displayed.
¤
¤ Paging only works if Session object is used to store and retrieve the
¤ dataset. The following is contained in the "DataGrid1_PageIndexChanged" Event
¤ Handler.
¤
¤ Datagrid1.DataSource = CType(Session("ds"), Dataset)
¤ Datagrid1.DataMember = "DataTable"
¤ Datagrid1.DataBind( )
¤ ___________________________________
¤ I just want to understand the reason behind this function although the
¤ desired result has been achieved.
¤
¤ Why didn't the datagrid display the next few rows of data if Session object
¤ is not used. Isn't the dataset stored in the memory and once called for by
¤ the Datagrid1_PageIndexChanged event handler, data would be immediately
¤ retrieved from there ?

I would never store a DataSet in a Session variable. First, you end up will old (latent) data and
second you eat up server resources.

Storing a DataSet in a Session variable is *not* required for paging. I would check out the
following:

http://aspnet.4guysfromrolla.com/articles/070903-1.aspx


Paul
~~~~
Microsoft MVP (Visual Basic)
 
¤ Paul,
¤
¤ Did you see my reply to Elton, that is for this sample as well.
¤
¤ Cor

Cor,

So you agree with me. That's cool. ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)
 
Paul,
So you agree with me. That's cool. ;-)
Click to expand...

No we don't agree in this one.

I find for a dataset that has to be updated the session the best of the in
fact somehow all bad solutions.

:-)

Cor
 
¤ Paul,
¤
¤ > So you agree with me. That's cool. ;-)
¤ >
¤
¤ No we don't agree in this one.
¤
¤ I find for a dataset that has to be updated the session the best of the in
¤ fact somehow all bad solutions.
¤
¤ :-)
¤
¤ Cor

Cor,

So you think it's wise to cache potentially large datasets on the server for extended periods of
time in a multi-user environment? At what point do you dispose of these session stored datasets? At
what point do you refresh the data to avoid latency?

Wouldn't querying the database when new data is requested, under the implementation of connection
pooling, result in a more accurate representation of the data as well as reduce the usage of system
resources?


Paul
~~~~
Microsoft MVP (Visual Basic)
 
Paul,
Cor,

So you think it's wise to cache potentially large datasets on the server
for extended periods of
time in a multi-user environment? At what point do you dispose of these
session stored datasets? At
what point do you refresh the data to avoid latency?

Wouldn't querying the database when new data is requested, under the
implementation of connection
pooling, result in a more accurate representation of the data as well as
reduce the usage of system
resources?


Paul
Click to expand...

There is in my idea no alternative if the data can be updated by any other
webclient meanwhile (some added rows by instance which give than another
index point with paging).

If it is a non updateable datatable, by instance a table of all countries
which is seldom updated. Than I tend for the shared class, which belongs in
a webapplication to all clients.

A session goes out of scope as soon as the user has not replyed before the
time that is set for that.
A dataset is completely disconnected, so connection pooling or whatever is
not a subject here.

:-)

Cor
 
¤ Paul,
¤
¤ > Cor,
¤ >
¤ > So you think it's wise to cache potentially large datasets on the server
¤ > for extended periods of
¤ > time in a multi-user environment? At what point do you dispose of these
¤ > session stored datasets? At
¤ > what point do you refresh the data to avoid latency?
¤ >
¤ > Wouldn't querying the database when new data is requested, under the
¤ > implementation of connection
¤ > pooling, result in a more accurate representation of the data as well as
¤ > reduce the usage of system
¤ > resources?
¤ >
¤ >
¤ > Paul
¤
¤ There is in my idea no alternative if the data can be updated by any other
¤ webclient meanwhile (some added rows by instance which give than another
¤ index point with paging).
¤
¤ If it is a non updateable datatable, by instance a table of all countries
¤ which is seldom updated. Than I tend for the shared class, which belongs in
¤ a webapplication to all clients.
¤
¤ A session goes out of scope as soon as the user has not replyed before the
¤ time that is set for that.
¤ A dataset is completely disconnected, so connection pooling or whatever is
¤ not a subject here.
¤
¤ :-)
¤
¤ Cor

Cor,

Whether the DataSet is disconnected doesn't really matter. When you use a session variable to cache
the DataSet, it's eating up web server resources. Multiply that by the number of concurrent users
and it could add up to enough resource usage to choke the web server, especially if you have other
web applications that are implementing the same technique. In addition, the solution does not scale
well.

Waiting for a session timeout isn't really a good solution for freeing up web server resources
consumed by session variables containing DataSets.


Paul
~~~~
Microsoft MVP (Visual Basic)
 
Back
Top