Discussion: DataSet over Session

[Alcar]

I personally still believe that keeping a Dataset stored in a Session Variable is, often, not a bad choice. And I'm sure I'm not the only one to believe this since I find examples that use the same solutions on many books, just an example: "Building Web Solutions with ASP.NET and ADO.NET" by Dino Esposito, Microsoft Press.
But then again I read alot of posts where this solution is rejected with passion. To the authors of these posts I would like to ask what really scares them about keeping a DataSet in a Session Variable and why.

 

[Zarcom]

With myself it runs back to when I was first learning to program. I was taught to avoid global variables whenever possible. I consider Sessions to be global and as such put them in the same category.

That beside, I feel that it decreases the scalability of your system by a lot. It is storing a large amount of data in memory that may not expire for the length of time the session is set for. In my code I try to make sure I deallocate variables as soon as I am done with them so as to keep the memory clean.
As I have posted else where.
Take a look at this article it sums up my feelings fairly well.

http://www.aspfaqs.com/webtech/faq/Advanced/faq4.shtml

That's my two cents anyway That'l do donkey, that'l do

 

[link9]

I'll expand just a bit, and say that it's simply a question of scalability and site traffic.

The more you bits you have in memory, the slower your site will run. You won't notice the performance hit until you get to a certain level of used memory, though.

So then, if you have a relatively low traffic site (and IMHO, most ppl do -- contrary to what we sometimes like to believe), then chances are that you won't get to that level, and therefore storing a dataset in session would be ok.

If you build your site using this methodology, your site would not be very "scaleable", to use one of our latest buzz words, because as the level of traffic grew, the number of datasets would grow in the same proportion as the number of users, and you would run out of resources much faster than someone who implemented some other methodology w/o using session at all.

In the latter case, the data is kept mostly on the client (the variables, that is) and they are passed back and forth on postbacks. In this way, as your number of users increased, the amount of resources it takes to support them increases by some factor less than your user n increase.

Here's one fact to consider: Data access (especially to SQL Server) has been vastly improved, as well as every aspect (string concat for the sql stmts, connection pooling, etc...) that it takes to get to that magic moment of data access. Due to this, hitting the database repeatedly for the same data just doens't cost as much as it used to. This would be another argument for the latter case from above.

So... is it a hard and fast rule NEVER to do this? No.

Is it a "best practice"? No.

Should we teach a beginner to do things in this way? IMHO, No.

As an experienced developer who knows his/her site's needs and limitations, should we be able to use this method if we know what the cost is? Yes -- w/o question, we should.

----------------

As for the not teaching beginners this method comment, I hate to go against Dino Esposito (and many others) here, but I just don't know why they do that. There's so much confusion because not only do they do it, but they don't even mention (in many cases) the cost of doing so. They are building simple little apps for examples and they do it because it's quick and easy. They don't take into account that they really should be employing "best practices" whenever possible and reasonable because ppl will take those little building blocks and try to build big apps out of them. It's shorsighted on their part to do it. I actually asked this question of Dino at a recent conference I attended because he was showing the exact same method at a session, and he said "Well, this is for a small example app.", or something to that effect. So it's not that they think it's great or anything... just that they sometimes get a little lazy in coding like the rest of us.

Personally, I don't do this. I abstract the logic of creating the datasets (or whatever) into re-useable classes and simply call them on each page. So my dev time is exactly the same either way, which is why I might as well choose the more scaleable method -- given the choice. And that's what I preach. That doesn't make it right, and it doesn't make it wrong. It just makes it what so many other things are -- developer's choice. They key is just to know what you're writing into your apps to make sure they fit the requirements... everything else is pure preference.

hth
paul

 

[jfrost10]

Heh, those silly Microsoft Authors.

I read in "OOP with VB.NEt and C#" that we aren't supposed to use identifying prefixes on any variables anymore
(i.e. intSomeNumber should just be SomeNumber).

It's unfortunate that certain developers books become gospel, and lead others into thinking they're learning best practices when really they should be considered suggestive opinions. Paul really summed it up best I think: do whats best for your site, and how you want to do it; just do it intelligently (i.e. scalability issues, architecture, etc.) and make sure you have reasons to back up your decisions.

Jack

 

[Alcar]

At this points someone would ask: "What are the limits in which we could use the session variables?". Maybe some examples would help the case.

I personally believe that in an intranet website, with 100 workstations, running on a 1Gbit network, you could consider in passing Large Objects with Sessions.

On an internet website with over 500 hits a day, you wouldn't choose such solution.

Would these be faily good limits?

 

[jfrost10]

I think you'd still have the scalability issue though.

For instance: What happens if the company balloons to 500 workstations in 3 different offices accross the country? If you have the architecture set up in a way that can scale to that no problem, then you're set. But if you went with the big-data-sets-in-session-variables, you'd have to go back and change any code you wrote to accomodate the larger volume.

So yeah, you could definately pass in the large objects with sessions. However, that might not be feasable down the road if any major changes to the company's infrastructure occur.

One thing to consider as well: although Sessions are great, you may be able to code around the whole issue. For instance, instead of holding a dataset to memory, you could dump it off to a hidden datagrid, or do like Paul suggested and just hit the database more often (which a few years ago would have been murder, but now isn't the case).

You know what would really help us give advice is if you told us a scenario that you would want to pass a dataset in a session. That way we could see why the large amounts of data need to be in memory for so long.


jack

 

[Alcar]

I usually don't leave my objects in sessions for too long. Once I finished using them I like to set all my Session Variables to nothing. But again I wouldn't really care that much if the application is a small one and works for few individuals.
If then the company grows, then their requests will increase, and sooner or later, no matter what I would have to put hands to the code again if not develop a brand new application. In that occasion I would not opt for the sessions, unless I'm required to.