USE_BLOCKING_THREAD

Another interesting email conversation between a developer and Dimitry Yemanov (Firebird core developer) produced this information:

Q.
What is the intent for the USE_BLOCKING_THREAD? I see it is enabled for all configurations except superserver. What is the rationale for that?

A.
The blocking thread (sometimes referred to as the AST delivery thread) listens for the blocking event notification posted by other processes and calls an appropriate BAST (blocking AST) routine inside the local process. This is necessary to asynchronously release or downgrade locks acquired by the current process but requested by other processes and is a vital part of the lock manager.

SuperServer doesn't need this feature as it performs direct AST calls from the lock requester to the lock holder (as everybody lives inside a single process).

The v2.5 embedded engine allows both in-process and cross-process interaction, thus it has the blocking thread enabled. For a single process embedded engine, USE_BLOCKING_THREAD may be undefined.

Cache flushes to disk and Firebird

The following fragment of a message appeared on the Firebird development list. As the question and answer are interesting, I thought I would put it on the blog.

"If I want to make cache flushes to disk very rare, do I set MaxUnflushedWrites & MaxUnflushedWriteTime to -1 or to some large value?
What other settings adjustments can make table flushes to disk more rare?
Is there any combination of settings that will keep the entire db in cache and never flush it to disk?"

Dimitry Yemanov answered as follows:

Forced writes = OFF (at the database level)
MaxUnflushedWrites = -1,
MaxUnflushedWriteTime = -1 (in firebird.conf)

With these settings, Firebird will never explicitly flush the cache to disk. However, flushes may still be performed by the operating system in the background. I believe you understand that these settings are somewhat risky from the database consistency point of view. There is no way to completely avoid flushes at all.