Re: Need to cache personalization data -- not sure which object to use

Discussion in 'ASP .Net' started by Rein Petersen, Jun 30, 2003.

  1. Hi Matt,

    Although this might be considered a matter of preference, I'd advise you to
    store "per user" information in Session. The Cache object is application
    scope and does not have dependencies to current user sessions (as does the
    Session object). Data islands are just xml embedded in an html document.
    Viewstate is webform session state control for interfaces.
    uses a cookie to store session data in the client so that each client can be
    uniquely identified and associated to session data stored on the server for
    that specific client.

    The session object is ideal for per user data because it can keep track of
    users that are connected such that a disconnected user's data will be
    dropped after the session expiration time. This will save your web server's

    You can enjoy use of the global.asax session_onload to make the call to the
    db to retrieve the specific user's favorites (or use a handler that inherits
    the IRequiresSessionState interface to store the data in session).


    "Matt Anderson" <> wrote in message
    > I have used ASP.NET to personalize our company intranet to store a
    > list of hyperlinks to intranet and internet web pages called
    > "favorites". The data is stored in SQL Server, per user, which they
    > can customize any time.
    > I created a user control to display the data in the margin of every
    > page, with DHTML to expand and collapse the folders.
    > The main problem is the performance. I need to cache the favorites,
    > but there are so many choices for this I'm not sure which way to go.
    > Session, Cache object, data islands, viewstate, cookies, etc.
    > One other issue I have is this: There is also an administrative page,
    > which resides in a virtual directory off the root of the same site,
    > which is used by the IT team to administer the favorites data in SQL.
    > There is also of course the page for the employee used to customize
    > the favorites data in SQL. If I use the Cache object, can I force an
    > update of the same cache object/key from both places?
    > Just want to hear what others have tried. Any and all advice is
    > appreciated.
    Rein Petersen, Jun 30, 2003
    1. Advertisements

  2. Rein,

    Thanks a million. I like the idea of using the quick-hitting
    superclass table and fetching the data as XML with XSLT. That method
    seems more reliable since it has fewer "moving parts", and I get the
    data back in a ready-to-render format.

    Thanks again.


    "Rein Petersen" <> wrote in message news:<#>...
    > Hi Matt,
    > > However, when I posted the original message what I was thinking was
    > > how to improve performance even more by only hitting the database only
    > > when the data has changed, not every time the user begins a new
    > > session. I have done this in a couple of web apps where when data is
    > > updated, an XML file of the data is moved by FTP to the production web
    > > servers for publication. When data is needed, a simple, fast XSL
    > > transformation is done without any need to go to the database server.

    > Serializing your data that way makes sense to save trips to the db but
    > introduces concurrency issues such that a user's changes/additions/deletions
    > won't appear immediately in his/her screen. There are options though. You
    > could install MSDE (a light/free version of SQL Server) on each of your web
    > servers (farm?) and replicate data from the main db to each machine -
    > concurrency is still a problem but at least the replication is automated and
    > simple. You add overhead to your web server which will probably reduce
    > performance.
    > You can use the cache object to serialize data (as xml) in a file that even
    > conforms to a schema. It is easily de-serialized in-process. Check out the
    > XSD.EXE tool included with the .NET framework. If the file were made
    > available to the web servers through a UNC addressable share on the db
    > server, a cache dependency could be placed on the file. Next, using the same
    > file as a signal file, an extended stored procedure can be called (by a
    > trigger upon change) to update the timestamp of the file and cause the cache
    > dependancy to drop (then reload fresh version in your code).
    > Or, you can create a superclass table that contains a row for each user's
    > object (his/her favorites relate to a single row in this table) that
    > contains a timestamp which is updated by a trigger (upon change). On the web
    > server, you can still use the session object to store the user's favorites
    > but perform a smaller read to the db to compare timestamp. If the timestamp
    > is different then just reload the data. Since ASP.NET uses connection
    > pooling, your communication to the db will be relatively minor.
    > I would venture the last option is probably the most performant. How you
    > store/serialize the data in session is a matter of preference, but if you
    > enjoy using XSLT, you might as well use SQL's native XML ability. Better
    > yet, SQL has a new XML managed provider that can query data using XPath and
    > returns XML that conforms to a mapping schema. It's quick, simple and ideal
    > for your purposes. Check it out...
    > Rein
    Matt Anderson, Jul 6, 2003
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Electrified Research
    Electrified Research
    Sep 23, 2006
  2. John
  3. Replies:
  4. Chuck
    Anthony Jones
    Feb 15, 2007
  5. Pat Hoback
    Pat Hoback
    Apr 8, 2004

Share This Page