Server Reference Guide : ASOLib--OpenROAD Server Library : OpenROAD Server Transaction Design
 
Share this page          
OpenROAD Server Transaction Design
The underlying architecture of the OpenROAD Server follows the dispatcher/slave model. A multithreaded dispatcher, called an SPO, manages multiple single-threaded ASOs. The ASO is where your 4GL application code is executed. The SPO can run on a different machine from the ASOs it manages, and OpenROAD Server applications can call other OpenROAD Server applications. This functionality, combined with the Name Server functionality of ASOLib, results in practically limitless configuration and application partitioning possibilities.
An application running under the OpenROAD Server can provide significantly improved performance over its fat client counterpart because of shared database connections, shared and cached object data, reduced network traffic, and so on. However, there are some precautions that are not necessary in a fat client system:
Avoid multi-query transactions (MQTs) that span SCPs. Although each client can have its own session context within the OpenROAD Server application, by default the OpenROAD Server application uses a single database connection and appears to the database as a single user. Therefore, MQTs should be atomic (fully completed, either committed or rolled back) within an SCP call. This does not mean that user operations must be contained within a single SCP. Put the MQT in the last of a multi-SCP sequence. You can, of course, perform your own database session connection management with multiple DBSessionObjects, but holding database locks between SCP calls is inadvisable.
Avoid unnecessarily lengthy processing within a single SCP call. The SPO dispatcher queues concurrent users of a particular ASO instance (or set of ASO instances). Although multiple ASOs can be managed by the SPO, and multiple SPOs can be used within the overall system, a given ASO instance is blocked while an SCP executes.
An OpenROAD Server application can act as a client to another application. This means that reusable modular component subsystems can be created that interact with each other. However, the calling OpenROAD Server application remains blocked; therefore, be careful not to make circular calls.