[fpc-pascal]Databases and FPC

[Rainer Hantsch]

Hello!

Good arguments....

On 6 May 2003, A.J. Venter wrote:
| The catch comes in when there is too many users at once (it seems to
| manifest around nine). The harddisk can no longer field all these
| requests to the same file very well and it gets corrupted. One user's
| time runs out and several get their status changed (knocking them off
| the system) etc. Not to mention that the system becomes unbearable slow
| as it waits for the harddrive to handle all these write/read requests.
| The problem of course is that a harddrive needs to make a full
| revolution to go one record backwards in the same file. So the harddrive
| is spinning out of control as the users work.

This is logical! When multiple programs start to edit one file, you are
definitely running in such situations. Even in case that you _optimize_ that
by only editing one record with seek()/read()/write(), you cause a
lot of activity on the disk. Well this will be cached by Linux very
well, but it must be finally done anyway!

| I expect therefore that your IRC services program would have the same
| problems, and suggest against this approach.

Exactly. Whenever you run code multiple times in parallel (which is the cause
here), you run into this problem. Therefore I would split all that into a
backend and frontend. While the frontends can run multiple times, there is
only one backend, keeping data files up todate and working primarily in
memory. So it is fast to the frontends and writes whenever it has time all
changes to disk. (A lot of programming, surely, but this has no bottle neck in
normal environment sizes.)


| I have seriously considdered mysql, but this has a problem here. Any
| user who discovers the mysql username/password could easilly edit the
| database and up his time considderably without paying. The flatfiles
| were binary, I doubt that many internet cafe users would be able to edit
| it. Even if they could, they are blocked at another point, I can use
| unix permissions. The counter app has SGID permissions and runs as the
| group that owns the database file. The normal users themselves do not
| even have read access to it.
| This option will no longer exist in a mysql backend.

Yes and no. - More NO. You can write some kind of "Middleware" which runs on
the MySQL Machine and uses a UNIX-Socket instead of a true network connection
and talks to small daemons on the workstations, too. So you can setup the SQL
server to only accept local connections and nobody will be able to access
MySQL from an external machine, because...
a.) no connections are accepted at all
b.) nobody knows username/password because it cannot be sniffed on the LAN.
So you have the benefit of SQL, too.


| | What other suggestions can you make ?
| It is vital that the database be frequently updated on disk because an
| internet cafe could lose a lot of money if a user who simply resets his
| thinclient workstation every few minutes never actually loses time.

An what about monitoring the T.C. from the server side and locking the
customer out when he is doing such things? There are many ways to detect such
situations!

mfg

  Ing. Rainer Hantsch

--
.---------------------------------------------------------------------.
|      \\|//              Ing. Rainer HANTSCH  -  Hardware + Software |
|      (o o)              Forget Windoze! -- We focus on L-I-N-U-X... |
|--oOOo-(_)-oOOo------------------------------------------------------|
| Ing. Rainer HANTSCH |  mail: office at hantsch.co.at                   |
| Khunngasse 21/20    |   www: http://www.hantsch.co.at               |
| A-1030 Vienna       |   tel: +43-1-79885380    fax: +43-1-798853818 |
| ** A u s t r i a ** | handy: +43-664-9194382   UID-Nr: ATU 11134002 |
'---------------------------------------------------------------------'