Subject AW: AW: [firebird-support] Firebird in automation
Author Alexander Gräf
> -----Ursprüngliche Nachricht-----
> Von: Adomas Urbanavicius [mailto:adomas@...]
> Gesendet: Mittwoch, 1. Dezember 2004 15:36
> An: firebird-support@yahoogroups.com
> Betreff: Re: AW: [firebird-support] Firebird in automation
>
>
> Well,
>
> It is interesting issue : if there are 20 connections, all
> are writing 50 records/sec, it would be much data safer than
> 1000 records/sec with single connection, wouldnt it ?
>
>

No, because if all runs quite symmetrical, for each connection it would take exactly one second to write the 50 records. If the server crashes, the transaction of each connection is rolled back:

20 Connections * (secs whithout commit) * (50 records written) = Number of records rolled back (lost)

which is the same as

1 Connection * (secs whithout commit) * (1000 records written) = Number of records rolled back

How save the data is depends solely on the rate at which transactions are commited. When commiting, data is forced to be written out to disk, which introduces latencies. Without commiting, it doesnt make a difference if the data was written to disk or not, because it will be rolled back anyway when reopening the database. Also, each connection introduces overhead like locking issues.

The simple approach would be: Deactivate all FORCED WRITES, make the page cache big enough, put the records into a queue, and try to get the write to database fast enough so that the queue wont fill up over time, with enough commits so that server failure wont drop work for several hours/days (e.g. one commit every 5 seconds).

Thats it, Alex