Prior to version V4.1.0 of InterBase, the server was designed in a way that is now called the Classic Architecture. In this design, each client connection to the server spawns a separate process. Each process does I/O directly to the database files, and negotiates access to the database files by interprocess communication methods like semaphores. Each of these server processes also keeps a cache of database pages in its own address space. When a connection terminates, the process that was spawned for it also terminates. The process' termination causes the memory that it allocated to be freed.
Version V4.2.X introduced a new server model called "superserver". The superserver model is a thread-based approach. This means that there is one process and a pool of threads to handle remote connections. So, for each remote connection threads are used to manage the connection, opposed to a new process in the classic model. The memory deallocation problem becomes more of an issue with the superserver model because of the server process never terminating. When a connection terminates the associated thread is placed back in the thread pool or terminated. However, neither of these actions affects the memory allocated, because memory allocation is process-based not thread- based.