Firebird 2.1 Release Notes

Global Improvements in Firebird 2.1
• the very Windows-knowledgeable might want to try out the concept of raw device storage on Windows
systems. It has not been a project priority to explore how it might be achieved on that platform. However, if
you think you know a way to do it, please feel welcome to test the idea in your Windows lab and report your
observations—good or bad or indifferent—back to the firebird-devel list.
•
Tip
V. Khorsun, D. Yemanov
Maintain your raw devices in aliases.conf. That way, in the event of needing to reconfigure the storage
hardware, there will be no need to alter any connection strings in your application code.
Feature request CORE-971
Remote Interface Improvements
The remote protocol has been slightly improved to perform better in slow networks. In order to achieve this,
more advanced packets batching is now performed, along with some buffer transmission optimizations. In a
real world test scenario, these changes showed about 50 per cent fewer API round trips, thus incurring about
40 per cent fewer TCP roundtrips.
In Firebird 2.1 the remote interface limits the packet size of the response to various isc_XXX_info calls to the
real used length of the contained data, whereas before it sent the full specified buffer back to the client buffer,
even if only 10 bytes were actually filled. Firebird 2.1 remote interface sends back only 10 bytes in this case.
Some of our users should see a benefit from the changes, especially two-tier clients accessing databases over
the Internet.
The changes can be summarised as
a. Batched packets delivery. Requires both server and client of version v2.1, enabled upon a successful protocol
handshake. Delays sending packets of certain types which can be deferred for batched transfer with
the next packet. (Allocate/deallocate statement operations come into this category, for example.)
b. Pre-fetching some pieces of information about a statement or request and caching them on the client side
for (probable) following API calls. Implemented on the client side only, but relies partly on the benefits
of reduced round trips described in (a).
It works with any server version, even possibly providing a small benefit for badly written client applications,
although best performance is not to be expected if the client is communicating with a pre-V.2.1 server.
c. Reduced information responses from the engine (no trailing zeroes). As the implementation is server-side
only, it requires a V.2.1 server and any client. Even old clients will work with Firebird 2.1 and see some
benefit from the reduction of round trips, although the old remote interface, unlike the new, will still send
back big packets for isc_dsql_prepare().
d. Another round-trip saver, termed “defer execute”, whereby SELECT requests will be held at the point just
before execution of the isc_dsql_execute until the next API call on the same statement. The benefit
of the saved round-trip becomes most visible where there is a bunch of SELECT requests whose result set
fits into one or two network packets.
This enhancement takes effect only if both client and server are v.2.1 or higher.
27