What is Batch Mode and When Should I Use It?

Using ADF Bindings and Data Controls, you are free to choose your front-end client technology and your back-end business service implementation. However, it's important to note that this consistency does not imply that all data controls are reduced to have the lowest common denominator functionality of a generic Java Bean. You work with the iterators, bindings, and data controls in a consistent way, but you also can take advantage of unique features offered by a particular data control provider.

For example, Figure 1 illustrates that the data control based on an ADF application module has a Sync property that the other data controls do not. In JDeveloper 10g, the value of Sync defaults to Batch to use the new batch mode.

Figure 1: Sync Parameter of a Data Control Based on an Application Module

Batch mode is a network roundtrip-reduction feature that, as its name implies, batches up data-related operations in order to perform them in more coarse-grained chunks.

The client layer works with its application module and its view objects to perform all of the setup operations on any view objects whose data is required by the current task at hand. These operations are batched up using a batch-mode specific client-side ApplicationModule implementation class, which ADF provides for you behind the normal ApplicationModule interface when Sync Mode is set to "Batch". Your application then makes a call to the following method to perform all of the data operations and retrieve all the data that you are expecting from the datasources in a single network round-trip:

yourBindingContainer.refreshControl();

When you call refreshControl() on the binding container, it calls the sync() method on the data provider of each data control in use in that binding container. In the case of an ADF Application Module running in batch mode, this data provider is the client-side ApplicationModule object. This sync() operation causes the pending operations and any data changes in the client-side cache to be sent to the server-side business service and get executed. Any data changes that are made by components in the middle-tier layer, either by executing queries or programmatically modifying data, will be returned back to the client cache in the same round-trip.

Eventually this batched mode of operation will allow improved application scalability even when client layer and business service are co-located in the same J2EE web container, by minimizing the span of time that any given client makes use of an application module from the pool. In our 9.0.5 and 10.1.2 releases of JDeveloper 10g, when running co-located like this, our Immediate mode still gives better performance.

We are focusing a lot of research and development effort on making batch mode the most scalable choice in the future, although we are arriving at that goal in phases. Even if you plan to deploy your client layer (like your Struts action classes) and business service layer in the same web container -- where reducing network traffic would not be a worry you have in mind -- batch mode can still provide value for you during development time.

When you run and test your ADF application in batch mode, it will guarantee to insure the best practices approach of working exclusively with component interfaces on the client layer, and never with the underlying implementation classes. The guarantees comes from the ClassCastException errors that you will get in batch mode at runtime if your client-layer coding has gotten "sloppy" and contains downcasts to the business service tier's *Impl classes (ViewObjectImpl, ViewRowImpl, EntityImpl, or ApplicationModuleImpl, or your own classes extending these).

Maintaining this best practice approach insures that you can easily redeploy your application into physically separate client and server layer at some later point in time if you decide you need to. It also insures that you can take advantage of clever new optimizations that the ADF team implements in batch mode for scalability in future releases. This explains why we've made Batch mode the default for JDeveloper 10g.

For now, my recommendation for web-based applications like the ADF Toy Store demo is to use Sync Mode of Batch during development and testing, but to switch to use a Sync Mode of Immediate before performing final tests and deploying in production. Changing the Sync Mode is as simple as flipping the property as shown in Figure 1.

A final important point about Batch mode is that the Oracle ADF DataAction tries to shield you from having to remember to sync your batch-mode application module. In fact, the default DataAction page handling lifecycle automatically performs the refreshControl() operation on your binding container at the appropriate times. Once during the prepareModel() phase at the beginning of the lifecycle handling, and once at the end of the request in the refreshModel() phase. This is designed on the assumption that it will be the view layer to be the first to access the data returned by the business service, so the batch mode sync operation occurs at the end of the data action lifecycle, before the Struts RequestProcessor forwards control to the page. If you need to iterate the data retrieved from the business service within the Struts action itself, then you'll need to need to make an extra call to refreshModel() just before your action code that needs to iterate the data. Failure to do so might result in an error like:

JBO-25048: Operation YYYYY is invalid for a working set view object

or other InvalidOperException type errors.

In versions of ADF beyond 9.0.5 that are currently in development, we've already made the automatic batch mode sync behavior even smarter to further avoid network round trips in cases where we can detect that there is no need to go over the wire. We've also further improved the ability for the DataControl to checkout the application module instance from the pool for an even shorter amount of time.