When a component acts directly on its representations or representation objects, this component must call the appropriate feedback functions declared on the classes IlsRpObject and IlsRepresentation so that the server is notified of the modifications. By default, each time one of these functions is called, a component-to-server transaction is implicitly created and committed, which results in the execution of a complete interaction cycle.

For instance, let us assume that a table representation is associated with a DepartementTable view and that a row object of type RowR belongs to this representation. The following code notifies the server of the following events, in this order:

At runtime, these events create and commit two component-to-server transactions, implying two interaction cycles.

To optimize component/server interactions, you should buffer notification and send a single transaction when a logical set of updates is completed.

The member functions IlsRpObject::beginC2SUpdate and IlsRpObject::endC2SUpdate control how notification to the server is buffered at each representation object level.

Now, let us modify the previous code so that only one interaction cycle is executed:

The interaction cycle with the server will be initiated only when the last instruction row.endC2SUpdate is executed.

You may want to discard the update notification currently buffered about an object. In this case, just call the function IlsRpObject::discardC2SUpdate, like this:

Buffering notification of updates at representation level is the usual practice.
It allows you to initiate an interaction cycle only when the whole representation
has reached a consistent state. This is the purpose of the member functions IlsRepresentation::beginC2STransaction and IlsRepresentation::endC2STransaction. Note that both buffer levels—that is, at representation-object level and at representation level—can be used simultaneously, as shown in this code sample.

In this example, only one transaction is sent to the server when the function IlsRepresentation::commitC2STransaction is called. This transaction notifies subscribers about the modifications of both row1 and row2. Declaring the functions IlsRpObject::beginC2SUpdate and IlsRpObject::endC2SUpdate on the representation objects is not mandatory in this example. However, this is recommended as an optimization technique that allows you to group all the modifications of the same object. Note that in this case, the modifications registered at object level are sent to the representation level only when the function endC2SUpdate is called.

The function IlsRepresentation::rollbackC2STransaction rolls back the modification currently registered at the representation level.

This rollback can be performed locally on the component, but you can also request the server to re-notify the current state of the modified objects so that the component is not constrained to implement its own rollback. This point will be discussed in “Default Component-to-Server Transaction Status”.. You can also refer to “Transaction Control” in the IlsMvComponent class description in the Rogue Wave Server Reference Manual.

Notification of changes can also be buffered at component level through the functions IlsMvComponent::beginC2STransaction, IlsMvComponent::commitC2STransaction, and IlsMvComponent::rollbackC2STransaction.

This mechanism allows the component to update a set of representations locally so as to initiate a single interaction cycle with the server.

Rogue Wave Server supports multithread component-to-server transactions. This means that you can begin, commit and rollback different transactions in different threads. To do this, just execute the function IlsMvComponent::setC2SMT after the component has been created.