!!!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 :
*[UPCALC]
*[UPUNDO]
*[UTTP]
*[UEGTS]

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.


----
![Notes|Edit:Internal.MULTIPLE PROCESSING THREADS]
[{InsertPage page='Internal.MULTIPLE PROCESSING THREADS' default='Click to create a new notes page'}]