Class sharing duing the web application running

Class sharing duing the web application running

• Maddu

  1. Client is each connection to the web application.

  2. Data is shared within one web application only. I want to share a dataset read from database because the data is frequently used by each field in web form. So if it is read form db every time, there are two many queries causing bad performance.

  Thanks

  Wilson

  
  

• Grendizer

  It depends on what you want to share and what you mean by clients. If you want to share within a single web application (but across multiple users) then static classes and/or instance classes stored in the application object will work. If you want to share data across multiple web applications then you'll have to rely on a separate component such as SQL Server or something. Web applications are for all intents and purposes running as separate applications and therefore can not easily see each others data. This is actually true for a single web application since IIS can actually spawn multiple processes to support a single web application (for scalability and/or app pool requirements) although this is uncommon.

  As far as sharing data in general your best option is to use SQL or another database to store your data and then have each client get its own copy (although each client could rely on a single set of classes you write to access this data). Another alternative is to use remoting to talk to a remote process that is running all the time. This will be slow though.

  Without more information it is difficult to give really good advice. In general I'd have to ask why it is important that you share the data across multiple clients If the data is large then it probably isn't a good idea to load it all into memory even if it is shared across multiple clients. A good caching scheme should be used instead. If it is painfully slow to retrieve the data then perhaps optimizing the retrieval and using better query parameters to filter out only the data you need (in addition to cache) will improve the retrieval time. Another problem with sharing data across multiple clients is concurrency. Unless the data is read-only multiple clients could modify the data at the same time. This will cause untold problems for you. DBs are optimized for this and therefore make a good repository for storing shared data that can change.

  Michael Taylor - 5/10/06

  
  

• pfitchie

  In that case the ASP.NET framework provides you several options. The HttpContext instance accessible through the page's Context property provides you access to the Cache property. The Cache is a dictionary of objects accessible to all sessions in the application. It is most appropriate for your case.

  To use the cache do the following:

  DataSet GetSharedData ( )
  {
  //Load the data from Cache
  DataSet ds = Context.Cache["somekey"] as DataSet;
  
  //If it is null then the data has not been cached yet so load it now
  if (ds == null)
  {
  //Load the data
  ...
  
  //Cache the data
  Context.Cache.Add("somekey", ds, null, Cache.NoAbsoluteExpiration,
  new TimeSpan(0, 0, 60, 0), CacheItemPriority.High, null);
  };
  
  return ds;
  }

  The above method (must be contained in the base Page class or somewhere that has access to the HttpContext) queries the data only once and subsequently gets it from the cache. Note however that the data must be concurrent-safe if you are going to write to it because multiple users could be accessing it at the same time. By setting the absolute or sliding expirations you can control how long the data will remain in memory before it is automatically dropped. Note also that if memory usage becomes too high then items in the cache will be automatically dropped. The priority controls the relative likelihood that the item will be dropped. Finally note that as of 2.0 you can set up a dependency on the data against a database. Therefore, through a dependency, if the database data changes your data can be automatically dropped from the cache forcing a retrieval the next time you need it. Also note that there is a callback that is invoked when an item is dropped so in theory you could always keep the data in memory simply by reloading it whenever it is dropped.

  To complete the discussion you should use the Session object to store per-user information (such as login information) that you don't want to persist for each request in the HTML stream or as a cookie. You should use the Application object to store global application settings. Although technically you could use the Application in the particular scenario you discussed it really should be reserved for read-only, global data that is relatively small. Finally you can store per-request data in the Items object. The Items object is cleared when the request completes. This is good for parsing and storing request and response information and for optimizing data sharing across a request. All these objects are accessible through the page's Context property. You can also get the current context through the HttpContext.Current property.

  Michael Taylor - 5/11/06

  
  
• Class sharing duing the web application running