Multiple Threaded Update Processes#
Some of the update processes in the application which are known to cause performance issues in the system have been upgraded to utilize both the application and database servers processing power. These update processes will now have the ability to run many tasks concurrently. This has been done by having the functions make use of multiple threading.
Multiple Threading Set Up#
A new function preference, DB PRCSS THREADS, was developed which flags the update processes to take advantage of multiple processors.This preference can be set up in IMFD or IMFN for the following functions :
The preference value (thread number) should be between 1 and 10. It is highly recommended that this value should be set to around 75 percent of the CPUs (Cores) available. If a value is entered greater than 75% of CPUs available, the function running may not complete.
For example, a database server with 2 Quad cores should be set to no higher than 6 CPU’s for update processes.
Parallel Work Engine Concepts#
- Threads are spawned when the work engine is started.
- Each thread holds its own instance of executions and a separate database session.
- The Parallel Work Engine queue holds a list of concrete implementations of Work Engine Task.
- As Threads complete tasks they grab the next task from the queue.
- Once there are no more tasks they sit idol until the parallel work engine closes them down.
- Each threads session changes are committed to the database before the database session is released.
Update Functions Using Multi Threading#
Only the most performance hindering functions have been upgraded to make use of multiple threading.
UPCALC#
- With only one CPU defined in the preference the function will process pays with the same logic as before
- Multiple CPU’s defined in the preference will cause the function to run the new PPCALC server code which is broken down into the following tasks
- Initialize Pay Run (Report launch thread)
- Initialize Session (for each Spawned thread)
- EE’s in the pay run are then added to a Queue and picked off and calculated by each of the spawned threads
- Commit Session (for each spawned thread)
- Finalize Pay Run (Report Launch thread)
- The user can display PAY_RUN_SEQUENCE and Thread number on the UPCALC report by specifying ‘PAY_RUN_SEQUENCE’ in the ‘User Comment’ parameter of UPCALC with the Trace level set to 0-Exceptions Only.
UPUNDO #
- With one CPU defined in the preference for the UPUNDO, the function will undo pays with same logic as before
- With multiple CPU’s defined in the preference, the function will run with the new java logic for the whole pay run and server code which is broken down into the following task
- Undo a Pay (for each Spawned thread)
UTTP #
- With one CPU defined in the preference for the UTTP, the function will generate scheduled shifts with the same logic as before
- With multiple CPU’s defined in the preference for UTTP, the function will process each work team as a threaded task
UEGTS #
- With one CPU defined in the preference for UEGTS, the function will generate time sheets with the same logic as before
- With multiple CPU’s defined in the preference for UEGTS, the function will populate each time sheet as a threaded task.
