View in .ashx handler?

I have a handler (for example, list.ashx) that has a method that retrieves a large set of data and then only captures the records that will be displayed on any given "page" of data. We allow users to sort by these results. Thus, any time I start the page, I get a dataset that I received just a few seconds / minutes ago, but reordering them or showing the next data page, etc.

I want to say that my data set has not really changed. Typically, a dataset is stuck in a page view, but since I use a handler, I donโ€™t have that convenience. At least I donโ€™t think so.

So, what is a common way to store a widget associated with the current user page when using a handler? Is there a way to take a data set, somehow encode it and send it back to the user, and then to the next call, transfer it back and then re-remove the data set from these bits?

I donโ€™t think that a session will be a good place to store it, since we can have 1000 users viewing different data sets of different data, and this can lead to the server kneeling down. At least I think so.

Does anyone have experience in this situation, and can you give me any advice?

+4
source share
3 answers

In this situation, I would use a cache with some type of user information and request as a key. The reason is because you are saying that it is a large data set. Right there is that you do not want to constantly raise and lower the pipe. Remember that your server should still receive data if it is in the ViewState and is processing it. I would do something like this that will cache it for a specific user and has a short expiration:

public DataSet GetSomeData(string user, string query, string sort) { // You could make the key just based on the query params but figured // you would want the user in there as well. // You could user just the user if you want to limit it to one cached item // per user too. string key = string.Format("{0}:{1}", user, query); DataSet ds = HttpContext.Current.Cache[key] as DataSet; if (ds == null) { // Need to reload or get the data ds = LoadMyData(query); // Now store it and make the expiry short so it doesn't bog up your server // needlessly... worst case you have to retrieve it again because the data // has expired. HttpContext.Current.Cache.Insert(key, ds, null, DateTime.UtcNow.AddMinutes(yourTimeout), System.Web.Caching.Cache.NoSlidingExpiration); } // Perform the sort or leave as default sorting and return return (string.IsNullOrEmpty(sort) ? ds : sortSortMyDataSet(ds, sort)); } 

When you say 1000 users, does that mean concurrent users? If your expiration time is 1 minute, how many concurrent users will make this call in a minute and require sorting. I think that offloading data to something similar to ViewState is just trading some cache for bandwidth and handling a large load of requests back and forth. The less you have to pass back and forth, the better, in my opinion.

+3
source

Why don't you use server side caching?

I understand that you are extracting a large amount of data, and then returning only the necessary records from this data for different clients. Thus, the HttpContext.Current.Cache property can be used for this.

eg. a property that encapsulates the data extraction logic (receives from the original data store with the first request, then puts it in the cache and receives from the cache with each subsequent request). In this case, all the necessary data manipulations (paging, etc.) can be performed much faster than receiving a large amount of data with each request.

In the case where clients have different data sources (each client has its own data source), the above solution can also be implemented. I believe that each client has at least an identifier, so you can use different caches for different clients (client identifier as part of the cache key).

+2
source

The best you can do is grow your own by including a serialized dataset in the body of the request to the ASHX handler. Then your handler checks to see if the request really has a body by checking Request.ContentLength and then reading from Request.InputStream and if it serializes that body back into the data set instead of reading from your database.

+1
source

Source: https://habr.com/ru/post/1308146/


All Articles