auto-backup across the net

[Jason White]

Provided that the "database" is not stored directly on the webserver which
is running the cgi, the connection state of the client/cgi is independant of
the connection state of the cgi/database.  A client will not lose its cgi
session if the cgi is unable to access the database.  A robust cgi can
handle redirecting where it will make its database connection, there is
never a need to inform the client.

The subject of redundancy in webservers and maintaining client/server
session data is a different issue.

Jason White

----- Original Message -----
From: "Austin Schutz" <tex at off.org>
To: "Jason White" <jasona at inetarena.com>
Cc: "Kari Chisholm" <karic at lclark.edu>; "Portland Perl Mongers"
<pdx-pm-list at pm.org>
Sent: Friday, June 21, 2002 6:48 PM
Subject: Re: auto-backup across the net


> On Fri, Jun 21, 2002 at 06:34:15PM -0700, Jason White wrote:
> > If we are talking about an internet, web-based setup, where client
systems
> > are accessing your databse, you have more immediate concerns on your
hands
> > than redundancy.
> >
> > If we are talking about a secure website, then the webserver should be
the
> > only system accessing the database, clients talk to the webserver and
the
> > webserver dishes out data.  The webserver is the only one(s) who need to
be
> > updated.  This can be done directly in your cgi(not the best solution)
by
> > testing for the presence of the required server/files before access,
>
> Ok, this was my point, but it still doesn't answer the question of
> how you tell the client. You test, find that something is broken, and then
> what?
>
> > by a
> > content-smart switch/router (hardware or software) which can re-route
> > traffic to a different destination IP when/if the original fails, or by
a
> > round-robin DNS set up, where is the defualt hostname fails, the DNS
table
> > switches to the second.  If clustering is setup, then it is entirly the
> > responsability of the cluster and is transparent to the developer.
> >
>
> These are true, but may be overkill or overly expensive. Also, I'm not
> sure if the DNS solution works if a connection is made. If a connection is
> made but the webserver or cgi returns an error, will the client be smart
> enough to use the other machines indicated by DNS?
>
> > If we are talking about a an intranet application where many clients are
> > accessing your database, try switching to a more server based model
which
> > can more closly model the options above.
> >
> Intranet applications I've programmed have known ahead of time
> about the location of redundant database servers. This works pretty well
> in my experience, and there's no reason it couldn't be done here. I still
> think the question of how you tell a client to go somewhere else is valid.
> What happens when e.g. the cgi can't access _any_ database server? Maybe
> the answer is just fail - but then again, maybe access would work from the
> same cgi on a different host depending on the particulars of the problem.
>
> Austin
>

TIMTOWTDI