Why isn't Refreshing the Browser Page Enough to Refresh the Data Displayed?

Send me a mail
 Dive into Oracle ADF   Click to see the XML version of this web page.   (Updated: 2/3/2008; 9:26:10 PM.)
Tips and tricks from Steve Muench on Oracle ADF Framework and JDeveloper IDE

Why isn't Refreshing the Browser Page Enough to Refresh the Data Displayed?

A pretty common question I see users having is:

  • User 1 is looking at a table on a web page showing some data
  • User 2 inserts or updates a row in the table whose data is shown on that page, and commits
    (This could be through a completely different application, for example)
  • User 1 clicks the browser refresh button to redraw the page, but User 1 doesn't see User 2's new/modified data

Why isn't Refreshing the Browser Page Enough to Refresh the Data Displayed?

The answer is fairly simple. When releasing your application module to the pool in the default "managed state" mode, we don't make the assumption that every time you render a web page that you also want to requery all of the data being displayed. Your binding container might have reference to data sets the drive the selections in drop-down lists, and perhaps those are rarely ever changing, so it would be wasteful to force those to requery each time. Since our application module pooling algorithm tries its best to keep your application module instance "sticky" to the same browser user that used it on the last request -- although it's not an ironclad guarantee -- you should have a good chance of not needing to requery all the data for a page each time it re-renders, which is good for performance.

That said, if you do want to force a single iterator in a binding container to re-execute its query each time, just override the prepareModel() method in your DataAction class and write a line of code like the following before invoking the super.prepareModel():

/* in overridden prepareModel() method */
actionContext.getBindingContainer().findIteratorBinding("YourIter").getRowSetIterator();
actionContext.getBindingContainer().findIteratorBinding("YourIter").executeQuery();
super.prepareModel(actionContext);

This will force a requery each time of just the data collection related to the iterator binding named YourIter in the current page's binding container. NOTE: The call to getRowSetIterator() is a workaround for Bug# 4443916 where calling executeQuery() in prepareModel() before calling super.prepareModel() gets ignored in immediate mode.

If you want to give the user a (Refresh) button that does the same thing, instead of forcing an iterator to re-execute its query on each render, then just add a button to the page like this:

<input type="submit" name="event_RefreshData" value="Refresh the Data!">

and then write a corresponding event handler method for your RefreshData event in the data action class of the page in question like this:

public void onRefreshData(DataActionContext ctx) {
actionContext.getBindingContainer().findIteratorBinding("YourIter").getRowSetIterator();
  actionContext.getBindingContainer().findIteratorBinding("YourIter").executeQuery();
}

If you want to give the user a button that will refresh all the iterators in the binding container on demand, you can just drop an "Execute" operation from the data control palette, and change the text on the button to say "Refresh the Data!", or whatever.

You might consider a helper method like this to make the code in the actions even easier:

  protected void executeQueryForIter(DataActionContext ctx, String iterName) {
    DCIteratorBinding iter = ctx.getBindingContainer().findIteratorBinding(iterName);
    if (iter != null) {
      /*
       * Calling getRowSetIterator reactivates the iterator that
       * might have been released in immediate mode. This is a
       * workaround for Bug# 4443916 where invoking executeQuery()
       * in prepareModel() for an iterator in immediate mode
       * gets ignored if called before super.prepareModel()
       */
      iter.getRowSetIterator();
      iter.executeQuery();   
    }
  }



© Copyright 2008 Steve Muench. Click here to send an email to the editor of this weblog.
Last update: 2/3/2008; 9:26:10 PM.