Well, he could then simply forget the external state server and gain another huge amount of speed :-)
And, if you talk of a farm etc., the state server MIGHT become the bottleneck at one point. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Jeff Reese [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 4. Juni 2002 21:02 To: [EMAIL PROTECTED] Subject: Re: [DOTNET] OO Architecture question... I'm curious why you say that it is necessary to make sure that a user stays within his original server. The original poster mentions that he would be using load balancing with a dedicated state server. Is there a reason other than state management that you want him to keep his users requesting the same server? Jeff Reese [EMAIL PROTECTED] -----Original Message----- From: Thomas Tomiczek [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 9:47 PM Subject: Re: OO Architecture question... (a) for web farms you need to make SURE that a user stays with his original server. This CAN be done - most load balancing systems support this, often on the basis of either: (1) redirecting the incoming user to a specific server, you find this on certain communities, where you are immediately redirected to a specific server in the farm. (2) redirecting the user on every request on the basis of a cookie set (session cookie, for sure). (b) you want to ensure that you have plenty of RAM :-) And IF you keep your data chunks small, then you can store a LOT. Another possibility THEN (if you run out of memory) is to use cache servers that store the data between the web server and the database server. Design with this in mind :-) Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Francesco Sanfilippo [mailto:[EMAIL PROTECTED]] Sent: Montag, 3. Juni 2002 20:20 To: [EMAIL PROTECTED] Subject: [DOTNET] OO Architecture question... I am designing a .NET web community app (ala MSN, Yahoo) in C#. I want it to be as OO as possible, but maintain scalability and performance. Here's what I have so far... Create a Member object when a user signs in. Run a single sproc that returns multiple result sets to populate various strings, ints, and DataTable properties of the Member object. Store the Member object in Session. DataTables represent 1-to-many relationships, like a member's buddy list. SELECT/UPDATE/INSERT/DELETE methods for each table are methods of the Member class. When a data-modifying method is called (UPDATE/INSERT/DELETE), the sproc returns a fresh copy of the data to repopulate the DataTable being changed. Outside of the initial bulk load, the DB is hit ONLY when a data-modifying method is called, since the user-specific data is pre-cached. This heavily minimizes DB hits, keeps small chunks of user data close at hand, and maintains an OO design. What I am concerned with is how well it will scale, perform with lots of concurrent users, and work in a web farm scenario (assuming use of a dedicated state server)? Also, would saving these DataSets for Members in Cache be better than stuffing them into Session? Thanks in advance... Francesco Sanfilippo ASP, .NET, SQL, C# San Diego, CA. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
