ASP.NET 2.0 Personalization

[RedHair]

How to use user profile within a web farm environment?

 

[Paul Glavich [MVP ASP.NET]]

The personalisation features in ASP.NET 2.0 are all provider driven as to
where to store data. By default, it will be stored in the Ap_Data directory
as a SqlExpress data file. This can be changed to use a standard SQL Server
provider (provided with ASP.NET V2) and therefore access a SQL Server
independent of the web servers. Obviously this database is shared between
servers in a web farm, so it should work fine in a web farm scenario. Use
the ASP.NET Configuration tool is VS.NET to change providers.

 

[RedHair]

Thanks for your reply.
Since the db should be shared between all servers within a web farm, does it
mean that
each time when the user requests a user profile property, the web servers
need to retrieve
the profile data from db again?

By the way, the web parts control works with the personalization mechanism,
is it possible
to read the web parts settings from db then store to another medium? (like
cookie) to reduce
the impact of frequent db access. Those settings is plain text or something
else in db?

 

[Paul Glavich [MVP ASP.NET]]

each time when the user requests a user profile property, the web

need to retrieve
the profile data from db again?

Yes, this is correct.

cookie) to reduce
the impact of frequent db access. Those settings is plain text or
something
else in db?

Certainly possible, but I have not done this. Also, you would have to
account for cookie restrictions on the size and types of information that
can be stored. Again its possible, but probably a little tricky. Bets bet is
to create your own provider for this.


--
- Paul Glavich
MVP ASP.NET
http://weblogs.asp.net/pglavich
ASPInsiders member - http://www.aspinsiders.com

 

[Paul Glavich [MVP ASP.NET]]

the web servers

need to retrieve
the profile data from db again?

Yes, and this will happen on demand anyway.

to read the web parts settings from db then store to another medium? (like
cookie) to reduce

I guess you could do it manually, or using a different provider, but it
would get kind if hairy in that you would need to make sure changes are
propagated back to the original source at some point. If stored in the
cookie (for example) you would have to not only cater for a cookies
limitations, but also save that changed info back to the DB later. Would be
tricky.

--
- Paul Glavich
MVP ASP.NET
http://weblogs.asp.net/pglavich
ASPInsiders member - http://www.aspinsiders.com

 

[Robert Smith]

guess you could do it manually, or using a different provider, but it
would get kind if hairy in that you would need to make sure changes are
propagated back to the original source at some point. If stored in the
cookie (for example) you would have to not only cater for a cookies
limitations, but also save that changed info back to the DB later. Would be
tricky.