Stand-by und Dynamische Workprozesse

Im Betrieb eines Applikationsservers kann es zu Situationen kommen, in denen alle Workprozesse belegt sind. Es kann zum Beispiel vorkommen, dass ein Workprozess einen weiteren Workprozess benötigt, um seinen Request zu bearbeiten. Insbesondere bei Einsatz von RFC belegen Dialog-Workprozesse z.B. wieder Dialog-Workprozesse. Bei Kaskaden von RFCs, die zur Parallelisierung der Last auf einem Applikationsserver eingesetzt werden, kann es so zu Deadlocks kommen.

Um mögliche Verklemmungen zu lösen, wurde das zweistufige Konzept der Stand-by und Dynamischen Workprozesse implementiert:

• Stand-by Workprozesse:

  Stand-by Workprozesse sind immer vom Typ Dialog (DIA). Beim Start des Applikationsservers wird die Anzahl der Stand-by Workprozessen dem Profilparameter rdisp/wp_no_restricted entnommen und gestartet. Während des laufenden Betriebes können keine weiteren Stand-by Workprozesse erzeugt werden. Sie werden im normalen Betrieb freigehalten und erst dann verwendet, wenn der Applikationsserver eine Verklemmung feststellt und aus diesem Grund weitere Workprozesse benötigt. In der Prozessübersicht (Transaktion SM50), sind Stand-by Dialog Workprozesse durch den Status Standby gekennzeichnet. In der Standardeinstellung ist der Profilparameter auf 0 gesetzt, so dass es keine reservierten Workprozesse gibt.

• Dynamisch nachgestartete Workprozesse:

  Dynamische Workprozesse können vom Typ Dialog (DIA) oder Verbuchung (UPD, UPD2) sein. Wenn alle Workprozesse eines Typs im Zustand Hält sind, startet der Applikationsserver einen Prozess diesen Typs dynamisch nach. Nachdem sich die Verklemmung gelöst hat, wird der dynamische Workprozess dann wieder vom Applikationsserver beendet. Der Applikationsserver kann somit durch das Nachstarten von dynamischen Workprozessen mögliche Verklemmungen selbstständig lösen.

  Beim Start eines Applikationsservers werden so viele Workprozesse gestartet, wie sich aus der Summe der folgenden Profilparameter ergibt:

  • 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

  Die Höhe des Profilparameters rdisp/wp_max_no wird beim Start des Applikationsservers automatisch auf die Summe der konfigurierten Workprozesse plus 5 dynamische Workprozesse gesetzt (insofern diese noch nicht durch Stand-by Workprozesse abgedeckt sind). Für den Fall, dass nur in Ausnahmesituationen mit Verklemmungen gerechnet wird, ist diese Einstellung passend. Falls viele RFC-lastige Anwendungen laufen, empfiehlt es sich, mehr dynamische Workprozesse zu konfigurieren. Wenn Sie mehr als fünf dynamische Workproesse konfigurieren möchten, so müssen Sie den Wert des Parameters rdisp/wp_max_no entsprechend erhöhen. Wenn Sie den Wert des Profilparamters manuell konfigurieren, so müssen Sie darauf achten, dass Sie den Wert gleich oder größer setzen, als die Summe der konfigurierten Workprozesse plus mindestens 5 für die dynamisch nachzustartenden Workprozesse.

  Mit dem Profilparameter rdisp/max_dynamic_wp_alive_time können Sie die Lebensdauer eines dynamischen Workprozesses festlegen. Mit Lebensdauer ist die Zeitspanne gemeint, die ein Workprozess aktiv bleiben soll, nachdem er den Request bearbeitet hat.

  Achtung Die maximale Anzahl von Workprozessen beträgt 512. Die Summe aller Workprozesstypen plus der möglichen dynamischen Workprozesse, sowie der Parameter rdisp/wp_max_no ist durch diese Zahl beschränkt.