Subject Re: Firebird and UPS advice
Author Adam
> When the client drops, it may take the server a long time to notice the
> connection is lost, depending on how you have the TCP/IP stack
> configured.

Default is 2 hours on both Windows and Linux

> In this case result sets and transactions will be held on
> the server, and may cause resource contention issues.

Or more correctly, TCP/IP does not require a constant connection
between two nodes. Each packet is routed seperately and arrives at the
destination in an undefined sequence. It does not make sense to talk
about a lost connection, except in conceptual terms, and what we mean
by that is that we did not receive any data or acknowledgement packets
from the other host in a particular time period.

So it is not until 2 hours that the server says to itself 'Haven't
head from connection 10 for a while, must be dead'.

> -----Original Message-----
> From:
> [] On Behalf Of tonyrobertt
> Sent: Friday, May 19, 2006 5:20 AM
> To:
> Subject: [firebird-support] Firebird and UPS advice
> Hi One of my clients are using firebird with five pc's. of which 3 are
> notebooks and 2 desktops. They want to buy UPS's but want to know if
> they shoudl only get it for the main server or also for the othjer
> desktop.

It is always a good idea to have redundant power supply to a server,
even though the database should survive the crash, it is not fun to
have to reinstall the stuff that does not guarantee to survive. Plus,
having 10 minutes extra power will mean that at least the notebook
users won't lose their work. I don't know the frequency of power loss
in your area, so whether it is worthwhile would depend on the amount
of extra work and frustration that would be caused by a power loss.

> In other words is it bad for the database to loose the
> connection to a client?. Can it cause corruption.

No, it will log it in its log, and it is bad in the sense that it is
not the preferable way to rollback a transaction and close a connection.

When you issue a rollback command, the server will piece by piece undo
everything your transaction did, then commit. This leaves less garbage
to clean up. So from that perspective, any records your uncommitted
transaction has modified will be read only to all other transactions
for 2 hours, and after that time, some transaction is going to have to
do that cleanup.

In simple terms, it will not corrupt the database but it should be
avoided where possible.