OpenROAD Server Pooler (SPO)
The SPO is a multi-threaded process that manages access from the OpenROAD Server clients to the 4GL business logic hosted in the ASO slaves. The OpenROAD Server supports three basic methods that can be invoked by an OpenROAD Server client:
• SPO Initiate method
• SPO Release method
• SPO Call4GL method
The behavior of these methods completely determines the OpenROAD Server characteristics. The SPO will process these method requests from the clients. It will either process the method internally or forward the method to the ASO slave. The description of these method behaviors in the SPO is described in the following sections.
How the SPO Initiate Method Request Works
The SPO receives an Initiate method request and performs the following processing steps:
1. The SPO checks to see if an ASO slave is already running with the same application signature as that in the Initiate request. (An application signature is the concatenation of the ImageFile value and the CmdFlags values passed in the Initiate method.)
2. If an ASO slave already exists with the same application signature, then the ASO slave UseCount is incremented and the client is bound to that ASO slave.
3. If an ASO slave does not exist with that application signature, then a new ASO slave is created and the Initiate request is forwarded to that ASO.
How the SPO Release Method Request Works
The SPO Release method can be driven explicitly by the client or implicitly when the client disconnects, exits, or times out.
The SPO receives a Release method request and performs the following processing steps:
1. The UseCount of the ASO slave associated with the client is decremented.
2. If the UseCount of the ASO slave reaches zero, then the ASO slave is scheduled for shutdown.
The OpenROAD Server Pooler is responsible for starting and stopping the ASO slave process.
How the SPO Call4GL Method Request Works
The client uses the Call4GL method to access the 4GL business logic that an OpenROAD Server hosts. It is the SPO's responsibility to validate this request and route it to the appropriate ASO slave.
The SPO receives a Call4GL method request and performs the following processing steps:
1. A check is made to ensure that an Initiate method request has successfully completed for that client.
2. A check is made to see if the ASO slave has been shut down because of inactivity. If it has been shut down, it will be started again using the original Initiate method parameters.
3. The Call4GL request is queued to the ASO slave for processing. If the application signature contains multiple ASO slaves, then the Call4GL request is queued to the least busy ASO slave.
4. The SPO is responsible for receiving the Call4GL method response from the ASO slave and routing it back to the client.
5. The SPO is also responsible to notify about any errors that the ASO slave may report. If the error is catastrophic, the SPO may shut down the ASO slave and start a new instance.
The SPO essentially acts as a router between the OpenROAD Server clients and the OpenROAD application slaves. The SPO handles multi-threaded requests from the clients and helps to ensure that requests are serialized before they are passed to the single-threaded ASOs.