Notification Cycle

The notification cycle takes place according to the following rules:

1. All incoming events from the data source (indirectly from Rogue Wave® Server) to the adapter are buffered until the end of the corresponding transaction, then they are processed in another thread.

2. The events are enclosed between the calls to the startBatch and endBatch methods.

3. Then, the method endBatch calls the protected method dispatchBatchedEvents to process all the buffered events in the Swing thread so that the graphical objects are updated in a multithread-safe way.

4. To preprocess and postprocess the dispatching of events, you can override the methods predispatchBatchedEvents and postdispatchBatchedEvents.

5. If you want to manage new types of events, you can override the methods dispatchBatchedEvent which is called by the method dispatchBatchedEvents for each event of the list. Note that the method isInBatchedEvent returns true while the method dispatchBatchedEvents is executed.

Figure 20.1 below shows two transaction processes between all the JavaTM data-source classes involved in a table view representation.

The dashed arrows represent server-to-component transactions (that is, the stack call of methods) from the server to the JTable object that can be viewed in graphical form by the end user.

The continuous arrows represent a component-to-server transaction from the end-user interaction with the JTable object to the Rogue Wave Server engine.

Figure 20.1 Transactions Between Java Data-Source Classes

Server-to-component transactions take place as follows:

1. A row representation object (IlsRpRow) receives an update from the Rogue Wave Server notification engine and notifies its associated table representation (IlsRpTable). Then, the IlsRpTable instance in turn notifies its associated IlsTabledataSource instance.

2. The data source notifies all its event listeners (in Figure 20.1, the adapter) with a call to the rowChange method. This method is called within a transaction, that is, between the methods startBatch and endBatch.

3. The adapter buffers all the update events, then the buffered events are processed by default in the Swing thread to enable the graphical object to be updated.

4. The default table model is updated by the adapter, the JTable object associated with the data model is automatically updated, and the end user can see the final result.

Component-to-server transactions take place as follows:

1. The end user modifies a cell value in the JTable object. This object updates the data model accordingly.

2. The adapter that has subscribed to the default table model receives the update of the cell value. Then, it uses the dsUpdateCell method to notify the data source about this event.

3. The data source initiates a component-to-server transaction and notifies its associated IlsRpTable instance about the update.

4. The IlsRpTable instance notifies the concerned IlsRpRow instance, and, finally, the Rogue Wave Server notification engine receives the update information.

In the next sections, we use examples to show how to use the various adapters.