Process Based Architecture New from S 39.5.16

Information

• Between server versions S39.5.0 and S39.5.16, a multithreaded approach was used in the architecture of the PLANTA server. In this approach, a new server process was started for each client connection and each session (i.e. client connection) was processed in the context of a thread.
• The process model of the server has been changed from server 39.5.16 insofar as each client session runs in an isolated process and can neither harm other sessions nor the entire server operation.

Motivation

The changes made to the process architecture bring about the following advantages:

• Stability: Session break-offs have no impact on the PLANTA server as a whole since the individual sessions are now separated from one another.
• Lower resource competition: Since exclusive resources, like e.g. the Python interpreter, are not only used by one session any longer, there will be performance improvements.
• Prevention of unnecessary resource reservation: In the case of a storage protection infringement, the respective session can safely be terminated right away. As a result, this storage will immediately be available again to the entire system.

Due to the changes described above, the new architecture will be a lot more robust against unpredictable errors in the future.

Modifications

• Each client session is run within a process (not within a thread, as has been the case up to now).
• The layer responsible for database communication and session administration is based on Java only.
• In parallel to this, a purely native component is running for approval of client connections and allocation of the DataDictionary (Master).
• The session component, which is also native and is created for each client connection, copies, e.g., the authentication, the module design, and the general event processing.
• For communication between the components, the PLANTA server uses serialized messages via protocol floats, which are exchanged by network sockets that can only be called locally.

Multi-Threaded Architecture	Process Based Architecture

Effects

• Upon successful server start, now at least three processes (service wrapper, PlantaServer, Master (DataDictionary, connection approval)), and for each session another process, are run, instead of two processes (service wrapper and PlantaServer).
• Since the communication is done via sockets, the maximum number of file descriptors must be increased.
• Sessions can also be quit individually by operation system means (kill, Task-Manager).
• Due to the process space division, a session crash/break-off has no direct effect on other sessions (e.g. storage violation, etc.).
• Instead of using a common Python interpreter, an own interpreter is integrated in each session.
  • Especially in cases of high parallel use of the server, this leads to an improvement of the performance since exclusive access is always given.
  • The interpreter can no longer be used for common use of data. At the same time, this prevents incorrect or abusive applications from causing the above mentioned storage violations.