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

[Rein Petersen]

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 asp.net interfaces. Asp.net
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
memory.

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).

Rein

"Matt Anderson" <andersonwebdev@hotmail.com> wrote in message
news:cbb0ed66.0306301200.257d64bd@posting.google.c om...

> 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.

[Matt Anderson]

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.

Matt

"Rein Petersen" <rmpetersen@jbogus.hotmail.com> wrote in message news:<#NdPKZLQDHA.2256@TK2MSFTNGP11.phx.gbl>...

> 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