Progress ABL is Inherently Single Threaded, Fat Client¶
Single Threaded¶
All Progress ABL programs are single threaded. There are no multi-threading facilities in the ABL. For example, there is no way to start a thread that runs ABL code in the same process or to block an ABL thread while another thread in the same process executes other ABL code.
When a program is executed in Appserver or WebSpeed mode, there is still a separate ABL process for each agent. Each of these ABL processes can only ever execute a single thread that runs ABL code.
Fat Client¶
When you manually run a Progress ABL program, you start up a binary executable (for example, _progres on Linux or UNIX and prowin32.exe Windows). That executable reads the program's file (source code or r-code) and interprets it. That program runs on the physical system on which the executable is launched. It runs within the context of the operating system's logged in user that launched the executable. This means that the Progress program can only access resources that the current user is permitted to access. This "manually" started program could be interactive (a ChUI or GUI client) or it could be non-interactive (a batch mode client). Either way the program conceptually runs as a client process in the context of some operating system user. All ABL logic for the program runs inside of that client process and there is one process for each user.
It is common for Progress developers to use the term "client/server" to describe this original implementation approach. In this concept, interactive or batch clients connect to a multi-user database process, which is considered the server part of client/server. Technically, the Progress database is a server but the split of the functionality between the database server and the client is heavily weighted toward the client side. One of the biggest benefits of the ABL is the ABL's use of the same language for both business logic and for data access. For example, WHERE clause expressions in queries are written in ABL. The non-obvious implication of this design is that any execution of the WHERE clause is done in the client process and not on the database server. The database server can really be considered an advanced indexing engine, it lacks much of the filtering and sorting capabilities that SQL developers take for granted. This means that many more records must be returned by the database to the client and the client handles the filtering. The ABL compiler attempts to minimize the negative impact of this design decision by implementing equality and range matching using indexes so that certain WHERE clause terms can be used to only walk only a sub-set of the records in that index. All the rest of the ABL WHERE clause is still executed in the client process and only some queries can take advantage of this feature. Likewise, if client-side sorting is to be avoided the query must be written to implicitly select an index that provides the same sorting that is needed by that query. In both cases, the real logic is implemented on the client.
We call this "inherently fat client" because there is always a per-user client process that executes all ABL logic and nothing is delegated to the database server. The approach is designed right in to the ABL.
When Progress implemented Appserver and WebSpeed, they did not eliminate this design choice. There is still a separate process running for each ABL program being executed. The fact that one now can call it over the network to invoke a program there, does not eliminate the fact that it is still a fat client. Progress just added a kind of pool of fat clients (agents) and a broker to distribute requests.
With the latest Pacific Application Server for OpenEdge (PASOE), there is some indication that ABL programs may be running on different threads in the same process, however it seems these must have important limitations on usage of client-platform dependencies. PASOE leverages a Java implementation in Tomcat to replace the old broker/agents architecture with a multi-threaded single process that does the dispatching.
© 2004-2019 Golden Code Development Corporation. ALL RIGHTS RESERVED.