Firebird Vulcan supports memory pools, but release-by-pool is deprecated. All new and revised code explicitly releases objects allocated. All objects track resources they allocate and release any remaining allocated resources in the class destructor.

The use of thread specific data other than thread management itself is deprecated. The “thread database” object has been retained, but is passed as a formal parameter to all methods and functions where it is required.

At one point the memory and processing necessary to maintain names was significant. Processor speed and memory cost have eliminated the benefit of that optimization, and Firebird Vulcan now uses names rather than identifiers. This change will allow “soft” system tables--system tables that accept and preserve user extensions.

In most cases, Firebird Vulcan exceptions are thrown and caught as instances of the OSRIException class. The OSRIException carries the full context (information load) of the exception, eliminating the need to find a target status vector in order to throw an exception.

Numerous internal mechanisms have been encapsulated as C++ classes including BLR generation, message formatting, message lookup, the mover, status vector, SQL parser, a string class, handle management, etc.

Firebird Vulcan contains a great amount of code shared between the engine, the Y-valve, other providers, and external components. To promote code sharing while preserving architectural borders, shared Firebird Vulcan classes are qualified by soft, component-specific namespaces declared in the build configuration.