Peter's Gekko

public Blog MyNotepad : Imho { }

Where to get your grid's data on the next roundtrip

In a recent post I wrote some things on a datagrid and what to do over roundtrips. In a comment John asked me what I did with the data over the roundtrips. He mentions 4 ways to store it. I always use the first one: a full reread from the DB on every roundtrip.

This is my situation:

The data might be changed on the next roundtrip. Actions on the form itself may have caused the changes.
The bottleneck is the bandwidth. The page's viewstate has to remain as small as possible.

The first point makes a database reread over roundtrips neccesary. In case only the second point applies it would be an alternative to store the data in the cache or session. Still I favor the database. My main reason is that a database server is designed / optimized for caching data and I don't have to reinvent the wheel. To be honest I never measured the difference with using the session or cache object. Given the updates in the DB I need a reread anyway. The apps behave well. The user load is not gigantic but a tiny box can serve all. At this moment I'm working on an application which will be under a greater stress. I hope (trust) the architecture will stand.

My main point is that bandwidth is far more important than server load. It's not a big problem to scale up to a bigger database server or to plug in some Mb's to store the sessions. That's all under your control. Widening the user's bandwith is not.

Having said this, I'm in for any other view. In 2005 it's a delight to see how you can configure caching right on the datasource itself.

Published Apr 21 2005, 03:21 AM by pvanooijen

Filed under: ASP.NET, Data

Comments

John Papa said:

Thanks for your feedback. I am on a project right now that does exactly that: rereads the data from the database on postbacks. The issue that I don't like is when records are removed or inserted into the mix when paging is involved (for example). You have 12 records, you have a pagesize of 10, you navigate to page 2, in the meantime someone deletes 3 of the records ... yuk. it is not insurmountable, just little thing slike that have caused me heartache. Why? Because I think that there should be a more elegant solution to this. OK, so that situation is not a killer, but here is another thought ... is hitting the database repeatedly better or worse for performance and scalability that storing the data in session? What if you have 25 users posting back to this page within a 2 second window (pretty realistic in many medium sized apps)?

This is one topic that I have tried a dozen different ways. I don't know what the right answer is beyond "it depends". Anyone and everyone, please chime in if you have experience with trying different techniques here.

And yes, i totally agree that it is so cool that you can configure caching on the datasource in Whidbey!

# April 21, 2005 6:21 AM

pvanooijen said:

Yes, rereading the data on every roundtrip makes your data quite "live". Records been gone, sort order changed, etc. But I think that is unavoidable. The state of a page is kept over the roundtrips but this state doesn't sync with the state (content) of the database. On returning to the server on the next roundtrip there are no assumptions you can make about the contents of the database. There is only one way to know what's in there : ask it by performing a query.

How heavy a load does this put on my database ? Given your scenario, 25 users / 2sec. Suppose the page requires two db queries, that makes 25 transactions / per second. (given 1 query takes 1 transaction (?)) Afaik thats no problem to even a small sql server.

In the danger of oversimplyfying things I take the luxury of feeding my code fresh data. And if things go wrong I'll take 2005 to cache at the datasource level. :)

# April 21, 2005 12:56 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?