Hi.

We are developing a intranet webapplication which about 20 users will be using a day.

We have alot of pages wich have lets say 30 rows with textboxes wich can be edited at the same time. So potentially a total of 30 update.

Our problem is if we should cache the EntityCollection (SelfService) wich we bound to the datalist.

One way is to fetch the collection bind to datagrid and save it in session. We of course have the problem that we potentially override an other users changes in database (wich mostly is ok). Then we could set the fields on the stored session EnitityCollection and let LLBL remeber state and save a lot of updates and then use the same session obejct to rebind again (we dont want potentially new rows from db since user didnt push search but only save)

Is this VERY bad practice when assuming low user load (memory) and that we dont mind that eg. on user change a price on a product and antoher user change to that product get overriden.

Thanks for your comments Anders

5 years ago, it would have been bad practise. However today more and more developers get convinced that if you need a program that will never reach the 100 user limit, you don't have to program it as if it will be used by hundreds of thousands of users needing 10 servers to get it going.

So your intranet application will be used by 20 users (let's make it a 100, your company grows a little ) but that's not shocking. Even if every user has 2MB of data in their session object, that's still 200MB of memory (in the 100 user limit) which is highly unlikely. Also, if you program clean, you can define 'per page' buckets in the session, for example on a non-postback page-load you clear this bucket, and on a postback you don't but re-use the contents. This way every page-change will clear the temp data of another page, you won't be carrying around a lot of data in the session object.

Overwriting data of A altered by user B is common. I wrote an article about this once: http://weblogs.asp.net/fbouma/archive/2003/05/24/7499.aspx

In other words: the only way it really works is if you merge data, any other method will throw away work, unless you lock the way to edit the data in the first place if its already edited by someone else. This then shows a bottleneck in the organisational structure of the work, so work can be done more efficiently if it's rescheduled.

So I'd go ahead with what you've planned.

Thanks alot for your comment. Good idea about clearing the session data on nonpostback. We actually had them remain in session.

I have some code for doing this sort of thing that I worked out for myself. It handles the concurrency issue. The cache is cleared every time the user goes to a new page. It seems to work pretty well, though I haven't looked at memory requirements to judge scalability. I think for scaling up to huge number of clients, putting the timestamp into view state, as discussed on another thread, might be good solution. But I cache the entity.

JimFoye wrote:

I have some code for doing this sort of thing that I worked out for myself. It handles the concurrency issue. The cache is cleared every time the user goes to a new page. It seems to work pretty well, though I haven't looked at memory requirements to judge scalability. I think for scaling up to huge number of clients, putting the timestamp into view state, as discussed on another thread, might be good solution. But I cache the entity.

Jim - I'm hoping you will see this post... How did you implement your cache clearing on leaving the page? Could post some code or some pseudocode or email at simon-underscore-beets-at-adp-dot-com?

Thanks!

Yes I see the post!

I will send you an email. Maybe what I have is not exactly what you need, but we'll see. Probably I will have to do it tomorrow (Saturday).