We *LOVE* the Session



  • At my current employer, our development team is fond of using the ASP.NET session for everything. And I do mean everything. While debugging an issue inside of a 2700+ line ASPX page (which is another WTF), inside of a 350 line button handler (which is yet another WTF), I noticed in the email log we have on every error that our Session variables list contains 43 items, including but not limited to several hundred lines of XML, two DataSets, one Hashtable and no less than three rich business objects.



  • @ObiWayneKenobi said:

    At my current employer, our development team is fond of using the ASP.NET session for everything. And I do mean everything. While debugging an issue inside of a 2700+ line ASPX page (which is another WTF), inside of a 350 line button handler (which is yet another WTF), I noticed in the email log we have on every error that our Session variables list contains 43 items, including but not limited to several hundred lines of XML, two DataSets, one Hashtable and no less than three rich business objects.
     

    At least they aren't in a hidden field that's passed page-to-page via a cross-page postback.

    {weep}



  • @Lorne Kates said:

    @ObiWayneKenobi said:

    At my current employer, our development team is fond of using the ASP.NET session for everything. And I do mean everything. While debugging an issue inside of a 2700+ line ASPX page (which is another WTF), inside of a 350 line button handler (which is yet another WTF), I noticed in the email log we have on every error that our Session variables list contains 43 items, including but not limited to several hundred lines of XML, two DataSets, one Hashtable and no less than three rich business objects.
     

    At least they aren't in a hidden field that's passed page-to-page via a cross-page postback.

    {weep}

    Isn't that what ViewState is for?  Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?


  • @C-Octothorpe said:

    Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?

    Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.

    I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session  but sparely and for integers alone ideally.



  • @callcopse said:

    @C-Octothorpe said:

    Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?

    Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.

    I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session  but sparely and for integers alone ideally.

    Worst first past ever.  0/10.


  • Care to elaborate, orthographic fail hack?



  • @callcopse said:

    @C-Octothorpe said:

    Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?

    Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.

    I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session but sparely and for integers alone ideally.

    Not sure if you're trolling, but I'll assume you're not.

    Firstly, ViewState and Session state serve two completely different purposes.  Comparing the two is like comparing a cars emergency brakes with their regular brakes.  Yes, you can argue that they kinda sorta achieve the same goal (stop the car), but they are implemented completely differently and are used for different purposes.  I would never use ViewState as a Session store, or attempt to hold view data in the session object.  If you're even considering that, you're doing it wrong...



  • @callcopse said:

    Care to elaborate, orthographic fail hack?
    I don't even know what this is supposed to mean.  I suppose that makes me an orthographic fail hack comprehension fail?

    But hey, let's take the entire page and cram it in the viewstate.  No need to worry about the client uploading 500KB/multiple MBs back to the server, right?  Everybody has a good connection, Shirley.



  • @callcopse said:

    Care to elaborate, orthographic fail hack?
    See my response.

    I don't mean to sound like a dickweed, but I've seen this too many times (view data in session object, tons of crap in session, huge viewstate objects, etc.).  Except for a few exceptions, you won't even need viewstate.  As someone on another thread has already shared, just turn off viewstate by default, and only enable where you need it.  It's a little more work, but you'll find that in most cases, everything will work as expected.



  • @Sutherlands said:

    comprehension fail?

    But hey, let's take the entire page and cram it in the viewstate.  No need to worry about the client uploading 500KB/multiple MBs back to the server, right?  Everybody has a good connection, Shirley.

    What I mean is - if you're liable to go in all attack dog on a shy little users first post you could at least spell properly. (Post <> Past).

    I'm not saying optimising page load is stupid, just that it is premature in some cases, and modern grids often do have a high impact on ViewState. Sometimes you might want to do something about that, other times who gives a flying one? (e.g. Only occasionally used by users logged in from business connections etc).

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    OK?



  • @callcopse said:

    What I mean is - if you're liable to go in all attack dog on a shy little users first post
    Fair enough, my bad.

    @callcopse said:

    you could at least spell properly. (Post <> Past).
    Whoops. Still didn't even see that.  Also, I saw "orthographic" and read it as "octothorpic"

    @callcopse said:

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    Why is a large ViewState ok, but a large Session is not?  I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server?  If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.


  • @Sutherlands said:

    @callcopse said:

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    Why is a large ViewState ok, but a large Session is not?  I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server?  If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.
    To be fair to callcopse, Session can be stored in a number of ways.  If it's in-process, then it's blazing fast and you're only limited by server memory.  Then there is state server, which IIRC is sent via binary serialization to another server, also a very fast method of session storage.  The other common one is SQL session state, which can be slow as it's a trip to the DB on the request, deserialize, [page lifecycle here], serialize and send back to DB, but scales well to a web farm.

    I'd also like to point out that callcopse *is* equating the two simply by saying he would rather have a large ViewState vs. large Session object.

    Either way, I'm curious as to why callcopse thinks Session is so much worse than ViewState.  Me thinks he read a single article proclaiming the virtues of ViewState over Session without performing any critical thinking after reading it.



  • @C-Octothorpe said:

    @Sutherlands said:

    @callcopse said:

    I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.

    Why is a large ViewState ok, but a large Session is not?  I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server?  If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.
    To be fair to callcopse, Session can be stored in a number of ways.  If it's in-process, then it's blazing fast and you're only limited by server memory.  Then there is state server, which IIRC is sent via binary serialization to another server, also a very fast method of session storage.  The other common one is SQL session state, which can be slow as it's a trip to the DB on the request, deserialize, [page lifecycle here], serialize and send back to DB, but scales well to a web farm.

    I'd also like to point out that callcopse *is* equating the two simply by saying he would rather have a large ViewState vs. large Session object.

    Either way, I'm curious as to why you think Session is so much worse than ViewState.  Me thinks you read a single article proclaiming the virtues of ViewState over Session without performing any critical thinking after reading it.

    Well, I am simply comparing the two evils, not saying one is used for the same purpose as the other, which you kind of implied as a bit of a sneaky dig. In-process session is not a great idea if there is any likelihood of app recycling - like there might not be on shonky old IIS. That leaves DB or Service State. I guess it is personal preference and shop working practice, and perhaps a hang over from classic ASP, days but leaving 'rich' stuff in DB session when you might just recreate seems rather pointless, and I prefer to avoid even a whiff of overwhelming State service. I don't 'prefer' large ViewState just sometimes don't think it the end of the world. Depending on usage.

    In terms of the 'recreate' above a rich object can be serialised / de-serialised from DB pretty simply, and it's a technique that is very effective - never missed a beat in doing that kind of thing (Usual provisos about updating object model etc)

    Are you making a case for loading session more heavily? Guess you might not have seen the fairly non-l33t servers we get to use...



  • @callcopse said:

    Well, I am simply comparing the two evils, not saying one is used for the same purpose as the other, which you kind of implied as a bit of a sneaky dig
    I was trying to defend and understand you, assuming that this was just a language barrier thing. I wasn't trying a sneaky dig, it's how you said it. Maybe you didn't mean to compare the two, but by saying you would prefer ViewState over Session state means that at a given point, you had a choice to use either ViewState or Session to store [object] in, and you would use ViewState.  So, indirectly, you compared the two.  If you said you're not, then fine, whatever.

    @callcopse said:

    days but leaving 'rich' stuff in DB session when you might just recreate seems rather pointless
    What the fuck are you talking about? You don't store your database information in session, and I never said you would or should.  You would, however, use it to store the users shopping cart, or preferences, etc.  Stuff that you can't get from the database.  And there is nothing wrong with SQL session state.  If you're in a farm where you have two or more load balanced web servers, then the only choice you have is either State server, or SQL session state (or custom, like a cache server).  I'm not sure why you're being a snooty prick about the different technologies/techniques. It only makes you sound uninformed and unwilling to learn.

    @callcopse said:

    In terms of the 'recreate' above a rich object can be serialised / de-serialised from DB pretty simply, and it's a technique that is very effective - never missed a beat in doing that kind of thing (Usual provisos about updating object model etc)
    Wha?

    @callcopse said:

    Are you making a case for loading session more heavily?
    No. Not sure where you got that.

    @callcopse said:

    Guess you might not have seen the fairly non-l33t servers we get to use...
    Are you trying to sound like a complete ass, or is this a language issue? I'm beginning to think that you're trying to sound like an agressive tard in hopes of scaring me off, and it might have worked if you weren't spewing complete and utter billshit.



  • @C-Octothorpe said:

    Isn't that what ViewState is for?
     

    Not really. It's meant to have information survive a page postback, but not interpage navigation. The following is probably not 100% accruate and won't make you a MCP, but:

    1) Session => Keep shit in memory for the whole website. IE: Which user am I logged in as?

    2) ViewState => Keep shit alove for the page you're on. IE: Which post am I reading?

    3) Context.Items or Form => Move shit between pages. IE: Take this textbox and jam it into the Preview page.

    I have no problem keeping large datasets in the viewstate, as long as you've looked into Server Side Viewstate. If you haven't, google it. It's a few LoC in Global.Asax, and a couple classes, and BAM, every single page stops emitting hundreds of kilobytes of extronious security-breaches-waiting-to-happen.



  • @Lorne Kates said:

    @C-Octothorpe said:

    Isn't that what ViewState is for?
     

    Not really. It's meant to have information survive a page postback, but not interpage navigation. The following is probably not 100% accruate and won't make you a MCP, but:

    1) Session => Keep shit in memory for the whole website. IE: Which user am I logged in as?

    2) ViewState => Keep shit alove for the page you're on. IE: Which post am I reading?

    3) Context.Items or Form => Move shit between pages. IE: Take this textbox and jam it into the Preview page.

    I have no problem keeping large datasets in the viewstate, as long as you've looked into Server Side Viewstate. If you haven't, google it. It's a few LoC in Global.Asax, and a couple classes, and BAM, every single page stops emitting hundreds of kilobytes of extronious security-breaches-waiting-to-happen.

    I appreciate the clarification, but I was just joking.  Didn't you read the rest of my post?  It was right next to the part that you responded to...  🙂

    EDIT: Yeah, I also did the viewstate provider for writing to the file system and a distributed cache server.



  • @C-Octothorpe said:

    @Lorne Kates said:

    @C-Octothorpe said:

    Isn't that what ViewState is for?
     

    Not really.

    Didn't you read the rest of my post? 

     Not really. :|

     

     



  • @C-Octothorpe said:

    You don't store your database information in session, and I never said you would or should.  You would, however, use it to store the users shopping cart, or preferences, etc.  Stuff that you can't get from the database.

     

    Wait, what?  If those things don't come from the database, then where do they come from?  In particular, at least on the last shopping-cart site that I had any hand in, the contents of the cart needs to be retained if the user logs out / closes browser / crashes browser and then logs back in.  (You might use session to cache things that you're confident won't change.)

     

    I mostly use session to retain things like, if the user

    1. goes to Reports.aspx?EntityID=1
    2. switches from January 2012 to September 2011
    3. runs some reports
    4. goes to Reports.aspx?EntityID=2

    then that second page starts out with September 2011 selected, without having to screw around with appending &Month=9&Year=2011 to every single variation of #4 that the user could click.  (The reason #4 is a whole separate page from #1 is that about 80% of the page content is potentially different from one entity to another.)

     



  • @emurphy said:

    @C-Octothorpe said:

    You don't store your database information in session, and I never said you would or should.  You would, however, use it to store the users shopping cart, or preferences, etc.  Stuff that you can't get from the database.

     

    Wait, what?  If those things don't come from the database, then where do they come from?

    Um ... at a first guess ... the user?

    @emurphy said:

    ... the contents of the cart needs to be retained if the user logs out / closes browser / crashes browser and then logs back in.  (You might use session to cache things that you're confident won't change.)

    So in other words you don't store your database information in session, you store your session information in a database (not necessarily the same one that C-Octothorpe is talking about).

     

    I mostly use session to retain things like, if the user

    1. goes to Reports.aspx?EntityID=1
    2. switches from January 2012 to September 2011
    3. runs some reports
    4. goes to Reports.aspx?EntityID=2

    then that second page starts out with September 2011 selected, without having to screw around with appending &Month=9&Year=2011 to every single variation of #4 that the user could click.  (The reason #4 is a whole separate page from #1 is that about 80% of the page content is potentially different from one entity to another.)

    You mean you don't get that from the database?

    You might not agree on the precise details of how to implement the examples C-Octothorpe threw out as just that - but it sounds like you're saying substantively the same thing.

     



  • @Watson said:

    You might not agree on the precise details of how
    to implement the examples C-Octothorpe threw out as just that - but it
    sounds like you're saying substantively the same thing.

    It looks like they are:


    @emurphy said:

    Wait, what?  If those things don't come from the database, then where do they come from?

    @Watson said:

    Um ... at a first guess ... the user?

    Talking cross-purposes here: an enumerated list (products available) will be constructed from data held in the database; a user's particular choice of one from that list (cart ID) will be held in the session, and more products being added to the cart will possibly be stored in the database but using the user's data to identify the location of their choices.

    Most session-based systems try to store as much data server-side where possible and only store minimal information within the session (or client-side), enough to reference the correct pool of data on the server.

    I'm no ASPX programmer, but the original WTF here sounds like everything is stored in the session to be passed back and forth between server and client here. That correct?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.