[fpc-pascal]Databases and FPC

A.J. Venter ajventer at direqlearn.org
Tue May 6 12:01:00 CEST 2003


I have been following this discussion with interest, as it relates to a
project of mine very closely.
For my icafe solution, http://akinimod.sf.net I used flatfiles of
record.
This worked beautifully, in fact I exploited the lack of real locking on
Linux for it, every user logged in, is running a counter program, which
reads his record in the database every 45 secconds or so to determine
his available time. 
Also when he logs out, the counter program changes his status in the
database. Yet another program, runs every minute from a cron job, and
removes a minute from each user who is currently logged in.

On windows this would obviously not work, because the OS cannot deal
with multiple users/processes writing to the same file. 

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.

I had in fact done several things to minimize search times etc. For
example, the database file is unsorted but when a user first logs in,
the counter program finds his record, and stores the file index in a
variable - all further reads and writes is then done directly with a
seek - saving the trouble of continous searching.

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

I now need to rewrite the backend of the system in a manner that will
protect it from these problems. Which brings me to my question, what do
you all reccomend ?
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. 

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.

TIA
A.J.
On Tue, 2003-05-06 at 11:44, Rainer Hantsch wrote:
> Hello, Peter!
> 
> This sounds good in the first moment (-> mmap), but I am afraid that this
> includes a small disadvantage:
> I can (possibly) feed a complete file with mmap() into memory, but this will
> be then obe huge data block. And this will make it much more complicated to
> work with in the case that you have to insert records. (This is at least my
> personal impression.)
> Though, when I load the file "manually" (meaning row by row and building my
> own dynamic list on the heap), I have available the full bunch of
> possibilities, can arrange the data as *I* wish, and so on. Gives me more
> flexibillity. - Am I right? :-)
> 
> 
> On Tue, 6 May 2003, Peter Vreman wrote:
> 
> | > Use a very fat machine with a lot of memory, the best will be to do that
> | > on
> | > the same machine where your IRC application is running, too.
> | > Write a "server" part which loads the whole "database file" into a dynamic
> | > list on the heap, hereby sorting it. Then it offers some kind of
> | > communication
> |
> | Under linux there is mmap() which will you let the kernel load the pages
> | of the database file on demand. See the man page of mmap for more info.
> |
> | Peter
> |
> | _______________________________________________
> | fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> | http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> |
> 
> 
> 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 |
> '---------------------------------------------------------------------'
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
-- 
Story of my life: "Semper in excretum, set alta variant"
A.J. Venter
DireqLearn Linux Guru




More information about the fpc-pascal mailing list