Session Tuturorial or Walkthrough for a newbie?

I am looking for a good walk through or tutorial on setting up session
managment or some kind of state managment.
This is what I am doing, so maybe you can tell me which direction I should
look at going!
I have a app then once you fill in your query information and sumitt the
form you get my results page. On the results page I have a datagrid that
contains anywhere from 5 to 7000 rows that are shown in a OutLookGroup style
.
I am finding that the table the grid builds off is very large to maintain in
viewstate, sometimes 12mb+. What I would like to do is in my grid only keep
what I need to display the grid and my row ID field, but I need to store the
entire table (which is created on the fly based on the query) in state
somehow, then call back to it on post to retrieve my details to further
process the page.
So I guess I need to do the following,
1. create the session (or whatever)
2. process the query and save table to session
3. onclick function retrieve the table from session and do secondary query
4. contrinue to maintain the table in session
5. after timeout dispose/flush table.
Can anyone give me good direction on where I go to make this happen?
Thanks;
--
D @dotnet.itags.org. premierdataHi Dewright,
AS for the caching table question you mentioned, I think generally the
following code the what we commonly used:
DataSet ds = null;
if(Session["data_key"] == null)
{
QueryDataFromDataBaseAndStoreIntoSession
();
}
ds = Session["data_key"] as DataSet;
We can put it in Page_load and bind the grid when necessary(We may adjust
the code according to our actual code logic). Also , for large dataset, of
course we suggest disabling the DataGrid's ViewState and bind grid with
data retrieved from SessionState(or other cache store) in each
request/postback.
Also, how do you think of the ASP.NET's Cache collection? Each ASP.NET
application will has a Cache colleciton assosciated with it, (it's
application scope ), we can store datas in it and add a expire dependency
for it. So for your scenario, you can also consider storeing the large data
records in Cache (with a sessionid associated key if necessary).
Here are some good resources for understanding the SessionState and Cache
in ASP.NET:
#Understanding session state modes + FAQ
http://forums.asp.net/7504/ShowPost.aspx
#State Management & Caching
http://msdn.microsoft.com/asp.net/a...te/default.aspx
Hope helps. Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Session unavailable in PostAcquireRequestState/PreRequestHandlerExecute

Hi all, I'm tearing my hair out here and I'm desperately hoping someone
has a fix.

I've got a .Net 2.0 web service for which I need session state, I can't
use cookies because I'm using the .NetCF, I used a cookieless session
and that was fine over Wi-Fi but borked horribly over GPRS, for which I
blame the ISP.

I implemented a quick hack with a SoapHeader containing the SessionId
and implemented a custom ISessionIDManager, now I just want to get some
data back out.

For reasons I'm unable to fathom, HttpContext.Session is unavailable
during PreRequestHandlerExecute. Even more bizarrely, the session is
unavailable during PostAcquireRequestState, the event that fires to
tell you that the session has been populated.

This issue affects .asmx and .axd files, but NOT aspx. The issue has
been raised before in posts going back (at least) to 2002 under the 1.0
framework.

The WebMethods involved all have EnableSession set to true and I can
access the session from the actual webservice, just not from any
application events that fire beforehand.

Does anybody have a workaround for this? I suppose I could drop the
session altogether and use the Application Cache to store a user's
credentials, but that's uglier than ugliness.

<code
public class AuthenticateRequestHttpModule : IHttpModule
{
private HttpApplication _HttpApp;

public void Init(HttpApplication httpApp)
{
this._HttpApp = httpApp;
_HttpApp.PostAcquireRequestState+= new
EventHandler(AuthenticateFromSession);
}

protected void AuthenticateFromSession(object sender, EventArgs
e)
{
HttpContext context = (sender as HttpApplication).Context;
if(null == context.Session)
throw new Exception("Isn't this a _really_ silly bug?");
}

public void Dispose(){}

}

</codeAdded the IRequiresSessionState marker interface. For some reason,
this seems to be required for non-aspx files in HttpModules, though it
worked without if I was access a web page.

I'd tried this before, but must have been handling an event too early
in the request lifecycle.

Session Tuturorial or Walkthrough for a newbie?

I am looking for a good walk through or tutorial on setting up session
managment or some kind of state managment.

This is what I am doing, so maybe you can tell me which direction I should
look at going!

I have a app then once you fill in your query information and sumitt the
form you get my results page. On the results page I have a datagrid that
contains anywhere from 5 to 7000 rows that are shown in a OutLookGroup style.
I am finding that the table the grid builds off is very large to maintain in
viewstate, sometimes 12mb+. What I would like to do is in my grid only keep
what I need to display the grid and my row ID field, but I need to store the
entire table (which is created on the fly based on the query) in state
somehow, then call back to it on post to retrieve my details to further
process the page.

So I guess I need to do the following,
1. create the session (or whatever)
2. process the query and save table to session
3. onclick function retrieve the table from session and do secondary query
4. contrinue to maintain the table in session
5. after timeout dispose/flush table.

Can anyone give me good direction on where I go to make this happen?

Thanks;
--
D @dotnet.itags.org. premierdataHi Dewright,

AS for the caching table question you mentioned, I think generally the
following code the what we commonly used:

DataSet ds = null;

if(Session["data_key"] == null)
{
QueryDataFromDataBaseAndStoreIntoSession();
}

ds = Session["data_key"] as DataSet;

We can put it in Page_load and bind the grid when necessary(We may adjust
the code according to our actual code logic). Also , for large dataset, of
course we suggest disabling the DataGrid's ViewState and bind grid with
data retrieved from SessionState(or other cache store) in each
request/postback.

Also, how do you think of the ASP.NET's Cache collection? Each ASP.NET
application will has a Cache colleciton assosciated with it, (it's
application scope ), we can store datas in it and add a expire dependency
for it. So for your scenario, you can also consider storeing the large data
records in Cache (with a sessionid associated key if necessary).

Here are some good resources for understanding the SessionState and Cache
in ASP.NET:

#Understanding session state modes + FAQ
http://forums.asp.net/7504/ShowPost.aspx

#State Management & Caching
http://msdn.microsoft.com/asp.net/a...te/default.aspx

Hope helps. Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Session Variables - Loosing

Hi,
I am using a web application -asp, ado, C#, using CodeBehind files etc..

I am using "InProc" session state and find that session variables are
loosing their values between one web form and the next. I have used "InProc"
on my development machine and the session variable values are being
maintained between pages.

I copied two of the relevant forms into another application and using
"InProc" session state they maintained their values between forms.

The Global and WebConfig files are virtually identical between applications.

This indicates to me that the problem is somewhere within my application but
I don't know where to start looking from here.

Any suggestions?

Thank YouWe had the same sort of problem here. It took the better part of a week and
another consultant to help out before we finally gave up and just decided
that .NET has real problems with Sessions.

Our solution eventually was to try commenting out different parts of the
code that was being run before the Response.Redirect. We narrowed the bug
down to a Directory.Move command - which really didn't make any sense to us,
but anyway. A Directory.Move just basically renames a directory on the
server's file system, so we tried instead to create a new directory with the
new name, copy the contents of the old directory over, then delete the old
directory (three lines of code instead of one). And Voila! Session keeps
it's state...

"Jonk Eidersteldvr" <hydraline@.cairns.net.au> wrote in message
news:3f4eab09_2@.news.brisbane.pipenetworks.com...
> Hi,
> I am using a web application -asp, ado, C#, using CodeBehind files etc..
> I am using "InProc" session state and find that session variables are
> loosing their values between one web form and the next. I have used
"InProc"
> on my development machine and the session variable values are being
> maintained between pages.
> I copied two of the relevant forms into another application and using
> "InProc" session state they maintained their values between forms.
> The Global and WebConfig files are virtually identical between
applications.
> This indicates to me that the problem is somewhere within my application
but
> I don't know where to start looking from here.
> Any suggestions?
> Thank You
>

Session Variables - why aren't novice developers warned?

When a user opens a new IE browser window using File-New-Window the
integrity of an application which relies on session state is COMPLETELY
undermined. Anyone who overlooks the fact that File-New-Window creates an
instance of IE in the same process with the same SessionID as the parent
window is in big trouble. This fundamentally restricts the usefullness of
using session state management.
I probably missed it somewhere - can someone please help me find where in
the Visual Studio 2005 documentation this pitfall is PLAINLY mentioned?
Such that developers sing basic guidance will not fail to note the
warning? There are articles which explain elementary concepts such as how
to create a session variable, without pointing out this serious hazard.
I have read the articles entitled Session State Overview, Session
Identifiers, Session State Events, etc. and I can't find this trap openly
described. For example, the article ASP.NET State Management
Recommendations identifies only performance considerations in the
Divantage of Using Session State section.
Why aren't developers warned of this while the basics of ASP.NET development
are being explained?
I agree that the injudicious use of global variables in any type of
application is sloppy and can incur pitfalls. However, in most types of
applications global variables are limited in scope to the instance of the
application. If there are multiple instances of the same application open
on one machine, each instance has its own scope. I think many (most?) asp
developers may have naive expectations that this is the case when using
session variables in an asp application hosted by Internet Explorer. I did.
-Bill
"GroupReader" <newsgroups_01@dotnet.itags.org.hotmail.com> wrote in message
news:1161148121.175510.124660@dotnet.itags.org.b28g2000cwb.googlegroups.com...
> You'll have these issues *any* time you use global variables in *any*
> type of application. It's best to use local variables whenever
> possible. In asp.net this translates to passing your variables around
> from form to form. Use querystring variables or form variables
> instead. Sorry I don't have a decent solution, but one more thought:
> I think your issue may get worse when IE7 introduces "tabbed
> browsing"... which makes it much easier to "open new windows". Maybe
> there's an IE setting that tells IE to start a new session when a new
> window is opened(?)
>Bill,
Unfortunatley, that's not the job of documentation. The docs are
meant to instruct on a particular subject, not to speculate on the pros and
cons. There are plenty of articles out there as well as books that discuss
these pros and cons in-depth. The pros and cons have been discussed now for
the better part of a decade so the information is there, it's just not the
place of the documentation to inform you of comparisons with other
technologies and with the pros and cons. It's the docs job simply to explain
and instruct on the particular topic. Before attempting to implement
something new, it's always useful to s out some of the info that's out
there on a topic. For example, there are plenty of articles out there on
session variables, how to use them in web-farms, high-jacking of cookiless
sessions, etc., as developers we just need to s them out as the docs are
never the be-all and end-all on a subject.
Hope this helps,
Mark Fitzpatrick
Former Microsoft FrontPage MVP 199...2006
"BillE" <belgie@.datamti.com> wrote in message
news:OZ2foZr8GHA.2288@.TK2MSFTNGP05.phx.gbl...
> When a user opens a new IE browser window using File-New-Window the
> integrity of an application which relies on session state is COMPLETELY
> undermined. Anyone who overlooks the fact that File-New-Window creates
> an instance of IE in the same process with the same SessionID as the
> parent window is in big trouble. This fundamentally restricts the
> usefullness of using session state management.
>
> I probably missed it somewhere - can someone please help me find where in
> the Visual Studio 2005 documentation this pitfall is PLAINLY mentioned?
> Such that developers sing basic guidance will not fail to note the
> warning? There are articles which explain elementary concepts such as how
> to create a session variable, without pointing out this serious hazard.
>
> I have read the articles entitled Session State Overview, Session
> Identifiers, Session State Events, etc. and I can't find this trap openly
> described. For example, the article ASP.NET State Management
> Recommendations identifies only performance considerations in the
> Divantage of Using Session State section.
>
> Why aren't developers warned of this while the basics of ASP.NET
> development are being explained?
> I agree that the injudicious use of global variables in any type of
> application is sloppy and can incur pitfalls. However, in most types of
> applications global variables are limited in scope to the instance of the
> application. If there are multiple instances of the same application open
> on one machine, each instance has its own scope. I think many (most?) asp
> developers may have naive expectations that this is the case when using
> session variables in an asp application hosted by Internet Explorer. I
> did.
>
> -Bill
>
> "GroupReader" <newsgroups_01@.hotmail.com> wrote in message
> news:1161148121.175510.124660@.b28g2000cwb.googlegroups.com...
>
Thanks for your response Mark.
I would ask why it is not a fundamental role of the Visual Studio
documentation to identify the potentially damaging risks associated with the
use of Session Variables?
I think it is a basic role of documentation to point out potential pitfalls
and provide guidance on correct usage.
Thanks!
Bill
"Mark Fitzpatrick" <markfitz@.fitzme.com> wrote in message
news:%23i1s3or8GHA.4572@.TK2MSFTNGP02.phx.gbl...
> Bill,
> Unfortunatley, that's not the job of documentation. The docs are
> meant to instruct on a particular subject, not to speculate on the pros
> and cons. There are plenty of articles out there as well as books that
> discuss these pros and cons in-depth. The pros and cons have been
> discussed now for the better part of a decade so the information is there,
> it's just not the place of the documentation to inform you of comparisons
> with other technologies and with the pros and cons. It's the docs job
> simply to explain and instruct on the particular topic. Before attempting
> to implement something new, it's always useful to s out some of the
> info that's out there on a topic. For example, there are plenty of
> articles out there on session variables, how to use them in web-farms,
> high-jacking of cookiless sessions, etc., as developers we just need to
> s them out as the docs are never the be-all and end-all on a subject.
>
> --
> Hope this helps,
> Mark Fitzpatrick
> Former Microsoft FrontPage MVP 199...2006
> "BillE" <belgie@.datamti.com> wrote in message
> news:OZ2foZr8GHA.2288@.TK2MSFTNGP05.phx.gbl...
>
I am sure we can all identify hundreds of ways that a novice could screw up
their entire application. It does not mean that MS can identify or document
all of them.
It is best to not make assumptions and to research how things work before
relying on them. That is what the job of a developer is - and sometimes you
can only learn by making mistakes. You don't put the blame on others.
"BillE" <belgie@.datamti.com> wrote in message
news:%23L4PAyr8GHA.4116@.TK2MSFTNGP03.phx.gbl...
> Thanks for your response Mark.
> I would ask why it is not a fundamental role of the Visual Studio
> documentation to identify the potentially damaging risks associated with
> the use of Session Variables?
> I think it is a basic role of documentation to point out potential
> pitfalls and provide guidance on correct usage.
> Thanks!
> Bill
>
> "Mark Fitzpatrick" <markfitz@.fitzme.com> wrote in message
> news:%23i1s3or8GHA.4572@.TK2MSFTNGP02.phx.gbl...
>
Marina, I certainly agree with everything you say - particularly in not
putting the blame on others!
However, I also feel that this potential hazard is severe enough that it
should be explicitly identified as a divantage. Worst of all, it is a
shortcoming that can go undetected, compromising data until finally noticed.
I expect there may be countless ASP applications deployed which are silently
adding orders to the wrong customer and the like because the developer did
not stumble across this issue.
You can research session state very thoroughly without finding any reference
to this damaging problem.
Respectfully, can you tell me where this issue is raised in MSDN, for
example, so that a developer responsibly researching the use of session
state prior to implementation would be likely to find it? Search on
"session state divantages" for example - performance is the only
divantage mentioned.
Thanks!
Bill
"Marina Levit [MVP]" <someone@.nospam.com> wrote in message
news:O%23AAO2r8GHA.940@.TK2MSFTNGP03.phx.gbl...
>I am sure we can all identify hundreds of ways that a novice could screw up
>their entire application. It does not mean that MS can identify or document
>all of them.
> It is best to not make assumptions and to research how things work before
> relying on them. That is what the job of a developer is - and sometimes
> you can only learn by making mistakes. You don't put the blame on others.
> "BillE" <belgie@.datamti.com> wrote in message
> news:%23L4PAyr8GHA.4116@.TK2MSFTNGP03.phx.gbl...
>
"BillE" <belgie@.datamti.com> wrote in message
news:et7L5Es8GHA.2120@.TK2MSFTNGP03.phx.gbl...

> I expect there may be countless ASP applications deployed which are
> silently adding orders to the wrong customer and the like because the
> developer did not stumble across this issue.
I feel that, if that were indeed the case, then it would be down to woefully
inadequate (more like non-existent!) testing...

> You can research session state very thoroughly without finding any
> reference to this damaging problem.
http://www.google.co.uk/search?sour...&q=IsNewSession
http://www.google.co.uk/search?sour...22new+window%22
Also this is a browser dependant problem, not really something caused by VS/
ASP.NET. Plus this is not necessarily a problem for most of us...
What is your scenario ?
Patrice
"BillE" <belgie@.datamti.com> a crit dans le message de news:
et7L5Es8GHA.2120@.TK2MSFTNGP03.phx.gbl...
> Marina, I certainly agree with everything you say - particularly in not
> putting the blame on others!
> However, I also feel that this potential hazard is severe enough that it
> should be explicitly identified as a divantage. Worst of all, it is a
> shortcoming that can go undetected, compromising data until finally
> noticed. I expect there may be countless ASP applications deployed which
> are silently adding orders to the wrong customer and the like because the
> developer did not stumble across this issue.
> You can research session state very thoroughly without finding any
> reference to this damaging problem.
> Respectfully, can you tell me where this issue is raised in MSDN, for
> example, so that a developer responsibly researching the use of session
> state prior to implementation would be likely to find it? Search on
> "session state divantages" for example - performance is the only
> divantage mentioned.
> Thanks!
> Bill
>
> "Marina Levit [MVP]" <someone@.nospam.com> wrote in message
> news:O%23AAO2r8GHA.940@.TK2MSFTNGP03.phx.gbl...
>
Possibly, Mark, but I think that even thorough testers might overlook the
possibility of clicking File-New-Window in Internet Explorer if they weren't
previously aware that it could cause problems. After all, they are testing
the application, not the behavior of Internet Explorer!
Which returns to the main point - how is a developer / tester to become
aware of this pitfall? The only way I can find reference to the problem it
is by specifically searching on something which implies prior knowledge of
the problem (like "Internet Explorer File New Window").
I appreciate the dialog.
Bill
"Mark Rae" <mark@.markNOSPAMrae.com> wrote in message
news:eB$KDOs8GHA.4644@.TK2MSFTNGP04.phx.gbl...
> "BillE" <belgie@.datamti.com> wrote in message
> news:et7L5Es8GHA.2120@.TK2MSFTNGP03.phx.gbl...
>
> I feel that, if that were indeed the case, then it would be down to
> woefully inadequate (more like non-existent!) testing...
>
> http://www.google.co.uk/search?sour...&q=IsNewSession
> http://www.google.co.uk/search?sour...22new+window%22
>
"BillE" <belgie@.datamti.com> wrote in message
news:uiKMIWs8GHA.4012@.TK2MSFTNGP04.phx.gbl...

> Possibly, Mark, but I think that even thorough testers might overlook the
> possibility of clicking File-New-Window in Internet Explorer if they
> weren't previously aware that it could cause problems. After all, they
> are testing the application, not the behavior of Internet Explorer!
Then they need to be testing the application under the various different
functional scenarios of the platform it's running under...
Opening a new window is just one of these. Same as the effect of turning
JavaScript off, etc...

> Which returns to the main point - how is a developer / tester to become
> aware of this pitfall?
Trial and error. Every new runtime scenario encountered by the development /
testing team gets added to the knowledge pool...
this problem falls into the same catergory, as the following problems
1) browser refresh - not handling a refresh of the page
2) double submit problem - not handling double second click while waiting
for render
3) use of static/vb modules to store session data
4) bloated viewstate
5) not understanding the page lifecyyle - page load fires on render and
postback, and before event firing.
all this problems are pretty easy to predict if the dev takes the time to
lean how a web applications work and its stateless nature.
-- bruce (sqlwork.com)
"BillE" <belgie@.datamti.com> wrote in message
news:OZ2foZr8GHA.2288@.TK2MSFTNGP05.phx.gbl...
> When a user opens a new IE browser window using File-New-Window the
> integrity of an application which relies on session state is COMPLETELY
> undermined. Anyone who overlooks the fact that File-New-Window creates
> an instance of IE in the same process with the same SessionID as the
> parent window is in big trouble. This fundamentally restricts the
> usefullness of using session state management.
>
> I probably missed it somewhere - can someone please help me find where in
> the Visual Studio 2005 documentation this pitfall is PLAINLY mentioned?
> Such that developers sing basic guidance will not fail to note the
> warning? There are articles which explain elementary concepts such as how
> to create a session variable, without pointing out this serious hazard.
>
> I have read the articles entitled Session State Overview, Session
> Identifiers, Session State Events, etc. and I can't find this trap openly
> described. For example, the article ASP.NET State Management
> Recommendations identifies only performance considerations in the
> Divantage of Using Session State section.
>
> Why aren't developers warned of this while the basics of ASP.NET
> development are being explained?
> I agree that the injudicious use of global variables in any type of
> application is sloppy and can incur pitfalls. However, in most types of
> applications global variables are limited in scope to the instance of the
> application. If there are multiple instances of the same application open
> on one machine, each instance has its own scope. I think many (most?) asp
> developers may have naive expectations that this is the case when using
> session variables in an asp application hosted by Internet Explorer. I
> did.
>
> -Bill
>
> "GroupReader" <newsgroups_01@.hotmail.com> wrote in message
> news:1161148121.175510.124660@.b28g2000cwb.googlegroups.com...
>