ASP, CGI and PHP Scripts and Record-Locking: What Every Webmaster Needs To Know   by Sunil Tanna

Many of us install server-side (ASP, CGI or PHP) scripts on our
web sites, and many of this scripts store data on the server.
However, poorly designed scripts can experience performance
problems and sometimes even data corruption on busy (and not so
busy) web sites.

If you`re not a programmer, why should this matter to you?

Answer: Even if you`re just installing and using server-side
scripts, you`ll want to make sure that the scripts that you
choose don`t randomly break or corrupt your data.

First, some examples of the types of scripts which store data on
web servers include:

(Of course, many scripts in each of these (and other) categories
are well-designed, and run perfectly well even on very busy web
sites).

1. Follow-up autoresponders typically store the list of
subscribers to the autoresponder, as well where in the sequence
of messages, each subscriber is. Examples of autoresponder
scripts: http://www.scriptcavern.com/scr_email_auto.php

2. Classified ad scripts store (at least) a list of all the
classified ads placed by visitors. Examples of this type of
script: http://www.scriptcavern.com/scr_classified.php

3. Free for all links scripts store a list of all links posted by
visitors. See some example scripts listed at:
http://www.scriptcavern.com/scr_ffa.php

4. Top site scripts usually store a list of the members of the
top site as well as information about the number of `votes` that
each has received. For examples of this type of script, see
http://www.scriptcavern.com/scr_topsite.php

So what kind of scripts have problems? And what sort of problems
am I talking about?

Well the principle problems all relate to what happens when bits
of data from multiple users needs to be stored on updated at the
same time. Some scripts handle these situations well, but others
don`t...

DATA CORRUPTION

Here`s a common data corruption problem that can occur with many
scripts:

1. When some bit of data needs to be updated, a copy of the
server-side script starts running, and then starts updating it.

2. If another user comes along and does an update before the
first copy of the script has finished, a second copy of the
script starts running at the same time.

3. There are a number of ways things can now go wrong, for
example:

(a) What if the first copy of the script reads in the data, then
the second copy reads the same data, then the first copy updates
the data, then the second copy updates the data? Answer: any
changes made by the first copy of the script can get lost.

(b) What if the first and second copy of scripts are both adding
multiple bits of new data to the store at the same time? For
example, imagine each needs to store the headline, description
and the name of the person posting a classified ad. Well, what
can happen (with some scripts) is the two classified ads can get
intermingled, so you might get (for example) HEADLINE-1,
DESCRIPTION-1, HEADLINE-2, PERSON-1, DESCRIPTION-2, PERSON-2.
Or worse yet, you might get bits of each part of each classified
ad, mixed with the bits of the other. This type of thing is
usually really bad news, as your data may consequently becoming
unusable from that point on.

Does this sound too unlikely a problem to worry about? Don`t bank
on it... even if it happens only 1 time in 1,000, or 1 in 10,000,
eventually it will happen: You need a solution.

So the real question is: is it possible for programmers to create
scripts without these kinds of problems? Fortunately the answer
is yes, and there are a number of ways that programmers can
address it:

1. They can store each bit of data in a separate file. This isn`t
necessarily a total solution by itself (in particular, a script
which just does this could still have problems if multiple copies
of a script update the same file at the same time), but it does
make data corruption less likely, and if corruption does occur,
at least it won`t corrupt the entire data store in one go.

2. They can use file-locking. This means that if one copy of a
script is working with a file, another copy of the script is
prevented from working on that file, until the first copy has
finished. File-locking works if done correctly, but programming
it into a script needs to be done very carefully and precisely,
for every single possible case... even a tiny bug or omission can
allow the possibility of data-corruption in through the backdoor!

3. They can use a database (such as MySQL) to store the data.
Provided the data is properly structured in the database, the
database handles the locking automatically. And, as the
programmer doesn`t have to write their own special locking
routines, the possibility of bugs and omissions are much reduced.

PERFORMANCE PROBLEMS

Of course, avoiding having your data corrupted should be the
paramount consideration in choosing a script, but is there
anything else we need to be concerned about?

Answer: Performance

Of course, all webmasters are aiming to build busy high traffic
web sites... but will your scripts be able to handle the load?

Go back and re-read the paragraph on file-locking. Now think about
what would happen if all the classified ads on your classified page
were stored in a single file (or all the links on your top site, or
all the subscribers to your autoresponder, etc.).

What would happen?

Answer: Because each update can only be performed after the previous
update has been completely finished, your site may be slow, or even
unable to handle all your users` requests.

So what`s the solution?

There`s two options that programmers can use:

1. They can use lots of small files and file-lock each
individually (for example, one per classified, one per top site
listing, etc.). Of course, this needs to be handled very
carefully...

2. They can use a database (like MySQL), as databases allow any
one individual record (`row`) to be updated, even when another
is also being updated.

IN CONCLUSION

Now, let`s summarise:

1. Scripts that store data in files need to use file-locking
to avoid data-corruption, and they also need to break the data
into separately updateable chunks to avoid performance problems
on busy web sites.

2. Scripts that store data in databases (like MySQL), provided
of course that they have been properly coded, are usually less
likely to suffer from data-corruption or performance problems.

And one additional point:

3. Even the best script is not immune to hard-disk hardware
failures, your web host being struck by lightning, and all the
other snafus that can happen. So, do take regular back-ups of any
data that you can`t afford to lose!

In short, even if you`re not a script programmer, you need to be
aware of data storage issues. In future, when considering a
script for your web site, don`t be afraid to ask some hard
questions about how it stores data and how well it handles multiple
users.

This article is Copyright (C) 2005, Answers 2000 Limited.

About the Author:
This article was written by Sunil Tanna of Answers 2000. For a
directory of ASP, CGI, PHP and Remotely hosted scripts, please
visit http://www.scriptcavern.com - and for scripts written by
Answers 2000 please visit http://www.scriptrocket.com
-----------------------------------------------------------------
-----------------------------------------------------------------

Publication Terms And Conditions:

Answers 2000 Limited grants you a free non-exclusive permission
(license) to publish a copy of this article on your web site or
opt-in ezine, subject to you complying with ALL of the following:

1. You must publish the article in full and unedited (except that
you may omit this Terms and Conditions section, you may omit the
word count, and you may correct any typos that you might find).
2. If you publish on a web site: (i) you must make ALL links
clickable, (ii) you may format the article to fit within your web
site`s design, (iii) you must include the copyright notice and
`About the Author` section at the end.
3. If you publish in an ezine: (i) your ezine must be opt-in with
your users having specifically elected to subscribe to your ezine
and with the ability to unsubscribe at any time, (ii) you must
include all link URLs unedited and in full, (iii) you may format
the article to your ezine`s layout, (iv) you must include the
copyright notice and `About the Author` section at the end.
4. To the maximum extent permissible under law, this article is
provided `AS IS` without warranties of any kind whether express
or implied.
5. These terms and conditions shall be governed by and construed
in accordance with the laws of England and Wales. Any disputes
arising from matters relating to this article shall be
exclusively subject to the jurisdiction of the courts of England
and Wales. You agree that any legal action against Answers 2000
Limited (or its directors, officers, or employees) relating to
this article or this agreement will be brought in the courts of
London, England, however Answers 2000 Limited reserves right to
pursue breach of these terms in any jurisdiction.

There are 1225 words in this article (including title and About
the Author section).

-----------------------------------------------------------------