Controlling the Steps of the Interaction Cycle

Interaction Cycles details the successive steps of an interaction cycle. We summarize those steps as follows:

1. When a component-to-server transaction is committed by a component, the server receives a transaction request.

If the server object transaction is successful, it is committed and a notification cycle is automatically triggered by the server. An acknowledgement request is returned to the interacting component.

If the server object transaction fails, it is rolled back and the server automatically rolls back the updated representations of the interacting component.

The following steps are executed on the instance of IlsMvServer or IlsMvProcess. Each step implements a virtual method which can be overridden, provided that the corresponding IlsMvServer base-class method is finaly called:

3. The function IlsMvProcess::beforeRequest is called as soon as a request is received on the communication layer.

4. The function IlsMvServer::beginTransaction is called just before the server object model is updated.

5. The function IlsMvServer::endTransaction is called just after the server object model has been updated. By default, this method commits the internal Rogue Wave® Server transaction, unless a rollback has been requested (by an editing function returning IlsFalse, for example). If the transaction is committed, a notification cycle is triggered and performs the following steps:

Reevaluation phase: Rogue Wave Server recomputes all the derived attributes that need to be reevaluated.

Notification phase proper: Rogue Wave Server notifies all the views that have subscribed to objects that have been modified during the transaction phase and the reevaluation phase. During this phase, two virtual methods are called: IlsMvServer::beginNotification and IlsMvServer::endNotification.

Reminder: Messages may be sent to the component in a separate thread if the dynamic view server has been initialized in multithread mode. See Dynamic View Server in Multithread Mode for details.

6. The function IlsMvProcess::afterRequest is called as soon as the notification cycle ends.

The application is not supposed to modify the server object model during the notification cycle. If necessary, you can use the function IlsMvServer::registerEndCycleTask to postpone the processing until the function IlsMvServer::endNotification is called.

The interaction-cycle phases described in the sections that follow can be optional, typically for optimization purposes: notification, acknowledgement,and representation rollback. You can also prevent Rogue Wave Server from using server object transactions to execute component requests.

You can prevent the server from executing the notification cycle and/or the acknowledgement after it has processed a component transaction request. To do this, you must pass a specific transaction status when committing the transaction on the component side. Here is a set of examples that specify various values for the enumerated type IlsC2STransStatus:

Important: Setting the transaction status value to ILS_C2S_NO_NOTIFY does not mean that the subscribing components will never be notified about the modifications performed on the server objects. In fact, they will be notified next time the server executes a notification cycle. Thus, this status value can be used as an optimization feature, for instance when a component has to commit several successive transactions.

By default, the execution of a transaction request in the server is interrupted and rolled back if one of the following events occurs:

An implicit call to the function IlsViewed::beginEdition on a server object returns IlsFalse. You should be aware that Rogue Wave Server executes this function on each server object associated with a representation object that is updated by the component transaction, including updated relation origin objects and target(s). This beginEdition function is called before the server object is edited.

An implicit call to the member function IlsViewed::endEdition on a server object returns IlsFalse. Rogue Wave Server executes this function on each edited server object the processing of a component transaction is completed.

You can prevent such a rollback in the same way that you prevent notification or acknowledgement. For example, if you do not want any rollbacks:

or if you want neither acknowledgement nor rollback:

When the no-rollback mode is selected, only the fourth event listed above (raising of a server exception) stops the editing of server objects. The subsequent steps (notification, acknowledgement) are performed according to the transaction status.

Important: In “no-rollback” mode, no internal Rogue Wave Server transaction is performed and the request directly updates the server object model. In this mode, the performance of the updating phase is far better, but there is no way to cancel the editing of the model.

It is possible to redefine the default component-to-server transaction status by using the member function IlsMvComponent::setDefaultC2STransStatus. In the following example, the component transaction is committed without requesting any acknowledgement or rollback:

You should be aware that when you set this status, you also specify the way a component transaction rollback will be executed:

By default, a component relies on the rollback services supplied by the server.

However, if you redefine the default component-to-server transaction status, you must require this service by adding the value ILS_C2S_SV_ROLLBACK in the status:

If this value is not added (as in the first example), any rollback initiated by the component will be processed locally without appealing to the server. This usually implies that the user has implemented its own rollback policy inside its component subclass. This can be somewhat tricky in the context of a distributed application where server notifications may interfere with local representation updates due to the activity of other components.