Differences Between Batch and Immediate Mode

Depending on the context, batch mode and immediate mode behave slightly differently. Please note the following differences; these are especially pertinent if you have a legacy application that you want to configure to use batch mode:

Synchronizing data between calls

If you need to pass information to the data control in order to properly setup the data model, for example to set bind variable values in view objects, you can do so in an overridden prepareModel() method on your DataAction before calling super.prepareModel(). This will sync the batch mode application module to the middle tier objects for you.

If you need to programmatically refer to data from view objects in your DataAction code in the controller layer, you should do so in a DataAction lifecycle method after prepareModel() has been called. Any user-written event handler method (onYourEventName() for example) or the invokeCustomMethod() lifecycle method will happen after the call to prepareModel().

Where possible, it is best to centralize all data-related setup/manipulation into a single application-module custom method so that all of the setup can be achieved in a single round trip to the middle-tier.

If the client/view code accesses the bindings API, then a call to bindingContainer.refreshControl() will perform sync() in any ADF business component application modules, or batch mode application modules.

In bindings, some actions will explicitly call sync():

if any navigation calls on the client lead to RowNotFoundException, sync is called to make sure there is no data on the server side as well.
PreviousSet and NextSet operations perform implicit sync on the associated application module.
execute forces a sync.
commit and rollback perform a sync on the associated application module (this is native in ADF business components; in general all transaction method calls lead to a sync).

JClient

Note that the strategies above using prepareModel() will not work in JClient, as there is no such phase or round-trip checkpoint. To implement the same strategy you would need to write such code in a button action to prepare the model for service requests for data.

Do not write business logic on the client

In general, you should avoid writing business-tier logic on the client side. This includes the UI, panels, and controller actions. Instead use a remote method on the application module or bean.

Using view criteria

If you are using view criteria to assemble WHERE clauses, the behavior of view criteria is different in batch and immediate mode. In batch mode, view criteria is cleared out when canceling out of find mode; in immediate mode, the criteria is retained when the user cancels out of find mode.

How currency of detail rowsets is set

Batch mode and immediate mode differ in how the currency of rowsets is kept. You could run into this difference if you have a master-detail table, have set the range size on the detail, and moved currency such that the first visible row in the range is not the first row of the detail set. The reason for this difference is that under immediate mode, whenever the master's currency changes, the detail query is re-executed to formulate the detail. Under batch mode, the detail sets are cached in the client.

For example, take the following example of two departments and their detail of employees:

Dept 10
Emp AA, BB, CC (3 detail rows)
Dept 20
Emp DD, EE, FF, GG (4 detail rows)

If you set the range size of Emp to 2, when you visit Dept 10 through a client you would see the following (** means the current row.)

[10]
[AA] **
[BB]

If you execute next on Emp (still on Dept 10), you would see:

[10]
[AA]
[BB] **

If you move to Dept 20, the cursor is still at the beginning:

[20]
[DD] **
[EE]

If you took the next range set on Emp (still on Dept 20), you would see:

[20]
[FF] **
[GG]

Now if you do next, you'd see:

[20]
[FF]
[GG] **

If you go back to Dept 10, you will see:

[10]
[AA] **
[BB]

Note that the currency for Emp was reset back to the first row (from [BB] to [AA]). So far, the behavior is the same between immediate and batch mode. However, if you go to Dept 20, the behavior will differ between batch mode and immediate mode. Under BATCH mode, you will see

[20]
[FF] **
[GG]

Under IMM mode, you will see:

[20]
[DD] **
[EE]

In batch mode, if the detail sets are refreshed from the middle tier, (if the client cache of detail range sets are refreshed/replaced by fresh detail sets from the middle tier), then it will revert as in immediate mode. In the above example, for Dept 20, it would go back to {[DD], [EE]}. To execute a refresh like this, call refreshDataModel() on the detail RowSet.