Skip to Main Content

Java Development Tools


For appeals, questions and feedback, please email

ADF table cached rows

Daniela VintuMar 29 2024


I'm trying to understand the caching mechanism used by viewObjects.

I have a simple table based on a viewObject (acces mode Scrollable, Retrieve from database all rows, in batches of 26, as needed).

On the model part, i've logged the number of rows added to cache:

public class BaseViewObjectImpl extends ViewObjectImpl {
  private int rowsInCache = 0;
  private int rowsInCacheLogged = -1;
  protected void executeQueryForCollection(Object rowset, Object[] params, int i) {
    rowsAdaugateInCache = 0;
    rowsAdaugateInCacheLogate = -1;
      super.executeQueryForCollection(rowset, params, i);
   protected ViewRowImpl createRowFromResultSet(Object object, ResultSet resultSet) {
    ViewRowImpl row = super.createRowFromResultSet(object, resultSet);
    int fetchedRowCount = 0;
    try {
      fetchedRowCount = getFetchedRowCount();
    catch (Exception ignore) {

    if (rowsInCache> 350 && (rowsInCache/ 50 != rowsInCacheLogged)) {"addCachedRow: " + rowsInCache + " in cache - fetched from DB: " + fetchedRowCount + " VO: " + getFullName +  " AM: " + getApplicationModule().getName());
      rowsInCacheLogged = rowsInCacheLogged/ 50;

In the UI, When I scroll to let's say record number 2500, I see the logged messages as rows are added to the cache / fetched from DB.

What I don't understand is the following behaviour: enter tha page, scroll to row 2500, (I see the logged messages as rows are beeing added to the cache), go to other pages, come back to this page - I see the table is taking longer to display - and then I see the logged messages as rows are beeing addded to the cache (all 2500)

In the taskFlow, before entering the page, I execute a method from the AM - that does myVO.executeQuery (I tried clearCache, rollback, same result) - why is my table (or it's iterator) fetching all the rows it used to have in Cache, although the current row in the tabel is the first record - the fetching starts when the table is being displayed in the page

Simple table:
<af:table value="#{bindings.GrupeArticoleVO.collectionModel}" var="row" rows="#{bindings.GrupeArticoleVO.rangeSize}"
                      emptyText="#{bindings.GrupeArticoleVO.viewable ? ' ' : ' '}" fetchSize="#{bindings.GrupeArticoleVO.rangeSize}" rowBandingInterval="1"
                      filterModel="#{bindings.GrupeArticoleVOQuery.queryDescriptor}" queryListener="#{bindings.GrupeArticoleVOQuery.processQuery}" filterVisible="true" varStatus="vs"
                      selectedRowKeys="#{bindings.GrupeArticoleVO.collectionModel.selectedRow}" selectionListener="#{bindings.GrupeArticoleVO.collectionModel.makeCurrent}" rowSelection="single"

Page def:
<iterator Binds="Root.ArticoleAM.GrupeArticoleVO" DataControl="CataloageAMDataControl" RangeSize="25" id="GrupeArticoleVOIterator"/>

I've made this simple example to understand some performance issues we have in our application - we have VO-s that could have a huge number or rows, but in every page we've made tha table ‘slow scroll’ (RowCountThreshold="-1" on every iterator) to prevent the user from scrolling ‘too much’ - but we see from time to time logged messages for fetches (100.000+ rows)

The solution to use maxFetchSize (globaly, in adf-config Row fetch limit, with the posibility of specific setting for every VO) is not exacly what I want - is good that it prevents this massive fetches from DB, but the problem is that 'it fools' the method getEstimatedRowCount, and the user does not receive an error message when it tries to scroll past that limit (it simply fetches the number of records specified, but the user is not aware that it could be more rows)

For now, we've raised an exception in the createRowFromResultSet when the number of records added is greater then the accepted limit (limit globally set, with override posibility for every specific VO)

We're also analysing the posibility of putting the big VOs on range-page access mode - but we have to put in ballance vs the extra loading on the DB side

Thank you,

Daniela Vintu

Post Details
Added on Mar 29 2024