In a client-server context a global process represents two things: a 4D process on the client and some resources on the server. In 4D v11 SQL global processes were re-architected such that the server side of the connection has 3 possible resources:

• A 4D process for all Application Server requests (e.g. Current Time(*))
• A preemptive OS thread for DB4D requests (e.g. QUERY(...))
• A preemptive OS thread for SQL requests

Over time the way in which 4D allocates these server resources has evolved in order to improve scalability. For example, the preemptive SQL request handler is created only as needed and has a built-in timeout. Since these processes do not persist, the server has more resources available overall. By adding a default timeout to the DB4D thread in 4D v12, the server can drop inactive DB4D connections therefore making more resources available to handle more connections.

The end result is that the ability of 4D Server to scale is not necessarily limited by the number of global processes (and therefore the number of clients).

4D v13 takes this ability to scale to the extreme by making all connections "as-needed". All three of the possible server resources for each global process are only created when they are needed.

Here is a summary of the evolution: