Standby and Dynamic Work Processes

When an application server is running, there may be times when all work processes are busy. The situation may arise where a work process needs a further work process in order to process its request. In particular when using RFC, dialog work processes reserve further dialog work processes. Deadlocks may occur when RFC cascades are used to parallelize the workload on an application server.

To resolve any deadlocks, the two-level concept of standby work processes and dynamic work processes has been implemented.

• Standby work processes:

  The type of standby work processes is always dialog (DIA). When the application server is started, the number of standby work processes is calculated from profile parameter rdisp/wp_no_restricted and then they are started. No further standby work procecesses can be created while the application server is running. They are kept free in normal operation and not used until the application server identifies a bottleneck and needs additional work processes to resolve it. In the process overview (transaction SM50) standby dialog work processes are indicated by status Standby. The profile parameter is set to 0 in the default setting, which means there are no reserved work processes.

• Work processes started dynamically:

  Dynamic work processes can have types dialog (DIA) or update (UPD, UPD2). If all work processes have status On Hold, the application server starts a process of this type dynamically. After the bottleneck has been resolved, the dynamic process is stopped again by the application server. The application server can resolve bottlenecks independently by starting dynamic work processes.

  When an application server is started, as many work processes as the sum of the following profile parameters are started:

  • rdisp/wp_no_dia
  • rdisp/wp_no_vb
  • rdisp/wp_no_vb2
  • rdisp/wp_no_enq
  • rdisp/wp_no_btc
  • rdisp/wp_no_spo
  • rdisp/wp_no_restricted

  When the application server is started, the value of profile parameter rdisp/wp_max_no is set automatically to the sum of the configured work processes plus five dynamic work processes (provided that this it not covered by standby work processes). This setting is appropriate if deadlocks are only expected in exceptional cases. If there are many applications transmitting a large number of RFCs, we recommend you configure additional dynamic work processes. If you want to configure more than five dynamic work processes, the value of parameter rdisp/wp_max_no must be increased accordingly. If you configure the profile parameter value manually, you must ensure you set a value equal to or greater than the sum of configured work processes plus at least five work processes that are started dynamically.

  With profile parameter rdisp/max_dynamic_wp_alive_time you can define the lifetime of a dynamic work process. The lifetime refers to the length of time a work process remains active after it has processed a request.

  Caution The maximum number of work processes is 512. The sum of all work process types plus possible dynamic work processes, and also parameter rdisp/wp_max_no, is limited by this number.