ASP.NET web farm with Oracle - design and deploy

29 Sep 2006 3:08 PM

yoram.ayalon

We have a web application running on classic ASP, where the session is
maintained in the Oracle DB, so every page redirect/form submit can
switch servers without any problem

we are looking now at writing a .NET application on the farm using same
Database. a couple of questions/notes:

- I understand you have to use "your own session provider" if you are
using non-SQL server. What exactly does it mean? Is there a standard
process that is executed automatically by .NET, and that we have to
implement using some established interface, or is it simply saying
"build some kind of code that will execute on every page, that will
set/retrieve the session in the Database?" if the former, where can I
find information on how to do it? if the latter, this is what we do
today anyway!

- Another issue is the "view state". is it true that if I set the code
to be constant, and not machine-dependant, then every post-back will be
OK even if redirected to another web server ? is that set on
machine.config level?

- for deployment, do we have to copy the same project to very web
server individually? is there a way to deploy to the farm in one go? or
a toll, that will replicate from one server to the others?

29 Sep 2006 9:27 PM

Gozirra

I'm sure you will find more detailed answers from others here but I'm
still going to make you look at my 2 cents.

To create your own session provider you must inherit
SessionStateStoreProviderBase and make the appropriate modifications to
the web.config. I'd suggest looking in MSDN for some examples. I have
never done this in the past so I'm sure someone can give you more
information if you need it. When running sites within a web farm we
have always used a single state server. This one machine was more than
capable of handling millions of users each day from a 6 server farm.

Viewstate -
Viewstate is stored on the page itself in a hidden field. This will
not be an issue within a web farm.

To answer your question about deployment - it all depends on what you
use to create your cluster. The one setup I have some experience with
was clustering using MS Application Center. In our setup you only
needed to install on the first node of the cluster. The software would
replicate changes to the other servers. At times, this update could
take up to 15 minutes but it was generally replicated in a short period
of time (under 1 minute). If someone changes a file on one of the
non-master servers, the change is quickly eliminated as the cluster
keeps all other servers synchronized with the master copy.

I hope I managed to make some sense. Its almost the end of the day and
I'm tired.