When using a Global semaphore it is possible to saturate the network with 4D Client/Server. For example:
While waiting for the semaphore to clear, this code can saturate your network because the loop is so tight. Since this is a global semaphore, it must be checked on both the client and server. Thus some network traffic is generated for each iteration. Since this loop will most likely execute very fast, a lot of network traffic will be generated.
A better solution is to analyze the design of the database and determine an appropriate polling interval to check for the semaphore. Does the process you are waiting on to clear the semaphore normally take a few seconds to complete (as opposed to a few milliseconds)? If so a longer polling interval would be far more appropriate, perhaps 1 second. For example:
DELAY PROCESS(Current process;60)
Note: the DELAY PROCESS command does not work for the User/Custom menu process and therefore the workaround stated above applies only to other processes. An alternative to using delay process is:
In this case the delay occurs in the call to Semaphore and this also reduces the network traffic.