ADF 10.1.2/10.1.3: Preventing eagerly querying of detail viewobjects

Question

Ever since we started developer ADF applications we had issues with database queries being performed when we didn't expect it. It turned out that this is the default behavior of the master-detail synchronization in ADF 10.1.2 and 10.1.3 (haven't tested 11 yet). I've come up with a solution of our own, which I want to share with you all. I also want to check if anybody here sees any drawbacks in this approach.
First some background info: Whenever the master view object is requeried or navigates to another row it requeries all detail view objects that have been queried previously. Detail view objects that are in their initial/clean state are not touched.
So, on the very first page of your application you might need DEPT and EMP, and they are automatically queried (since the ADF bindings are refreshed). However, when you navigate to the next page it might only use the DEPT ViewObject. If you navigate to another DEPT, the EMP query is also re-executed even if this next page doesn't have a binding for EMP.
Steve Muench described a possible workaround (number 74) at
http://radio.weblogs.com/0118231/stories/2004/09/23/notYetDocumentedAdfSampleApplications.html
Although his solution works, we didn't really like it. Here's a summary of his approach:
<ul>
<li> add a method <tt>enableDetailsForViewInstances()</tt> to the ADF BC Application Module. This accepts an array of view instance names representing the views used on the current page. It then enabled/disables the master-detail synchronization for each viewlink based so that only the viewlinks relevant to the current page are enabled.</li>
<li> add a custom <tt>JSFPageLifecycle</tt> class that overrides the <tt>prepareModel()</tt> method.
This methods assembles a list of all view instances used by the iterator bindings of the current page. It then calls the method on the ADF BC Application Module to enable/disable the viewlinks</li>
</ul>
The Application Module disables master-detail synchronization by calling <tt>removeMasterRowSetIterator()</tt> on the detail viewobject. This removes the master-RowSetIterator from the default RowSetIterator of the detail VO, effectively breaking the link. The old master-RowSetIterator is kept in a HashMap. Later, when both the master and detail VO are used on the same page the link is restored by calling <tt>setMasterRowSetIterator()</tt> on the detail with the master-RowSetIterator stored in the HashMap.
The main objection we had to this approach is that you are pushing the relevant viewobjects from the View layer to the Model layer. We would like the Model not to be too knowledgable about the View layer. Also, this means things break if you get a hold of a detail viewobject some other way, for instance by calling findViewObject on the AppModule or by having an old reference to the detail VO. If you get hold of such a VO instance without calling <tt>enableDetailsForViewInstances()</tt> it would not have a master-rowsetiterator and an exception is thrown about the bind parameter from the viewlink being null.
I tried to find a solution that is transparent to the View layer or other client. I wanted a solution where the eager master-detail navigation is disabled and the detail would only be requeried/refreshed when explicitely called for. This could either be your custom code calling the ViewObject or the JSF View layer having an ADF binding to the ViewObject. Basically I want to try to reset the detail ViewObject to its initial/clean state as the master VO won't requery the detail VO's that are in the initial stage. It only requeries the detail VOs that have a default RowSet and RowSetIterator.
After quite some digging around I came up with:
<ul>
<li>clear/close the <tt>RowSetIterator</tt> on the detail <tt>ViewObject</tt> when navigating to another row in the master <tt>ViewObject</tt>. To do this, we use a <tt>DetailClearingListener</tt> class that implements the <tt>RowSetListener</tt> interface.</li>
<li>The <tt>DetailClearingListener</tt> class implements the <tt>navigated(NavigationEvent event)</tt> method. This gets executed when the (master) ViewObject navigates to another row. In this <tt>navigate()</tt> method I iterate over <tt>ViewObject.getViewLinks()</tt> to find all the links where the navigating ViewObject is the source (=master). Then I look at the ViewObject from the destination (=detail) part of the link.
For each detail ViewObject I get the RowSetIterators by calling <tt>ViewObject.getRowSetIterators()</tt>. Then I close all these RowSetIterators by calling <tt>closeRowSetIterator()</tt> on them</li>
<li>The tricky part was to properly register this listener with the master ViewObject. As it turns out, you can call <tt>addListener()</tt> on the ViewObject, but in fact it is just relaying this to the default RowSetIterator of the ViewObject. It's the RowSetIterator that registers the listeners and calls them when required. This proved to be a problem, when a ViewObject is both the detail in a master-detail relationship and also the master in (another) master-detail relationship.
With the DetailClearingListeners in place, the first (highest) master-detail relationship will close the default RowSetIterator on it's detail VO when navigating the master. Unfortunately this also destroys the registered listeners on this default RowSetIterator that need to managed the lower master-detail relationship.
The only workable solution we could find is to override the <tt>getDefaultRowSet()</tt> method in the ViewObject and register the listener there. This means that whenever the default rowset (and rowsetiterator) is requested, we make sure we register the DetailClearingListener before returning the rowset. Since we can't test if the listener is already registered it does mean we frequently register the listener even when it is not necessary. Luckily enough the internal implemention does prevent duplicates and will ignore any new listeners that are already registered. This is why we are creating only a single instance of the DetailClearingListener and store it in a private member variable of the ViewObject. That way, we use the same DetailClearingListener instance each time and duplicates are prevented.</li>
<li>The big benefit of this approach is that only relies on changes to the ViewObject. This can easily be implemented by giving all your ViewObjects a common superclass that implements this solution. In most cases, you already have an application- or enterprise-wide ViewObjectImpl class that is the basis for all your ViewObjects. In that case, you can just implement the solution in that global class.</li>
</ul>
We've tested this solution in ADF 10.1.2 and 10.1.3 applications and found dramatic performance gains. We had one application were page requests took 10-15 seconds once you visited all pages in the application (thereby activating each ViewObject at least once). It was not uncommon for a navigation to another row in the master ViewObject to trigger 70-100 queries, since all the detail (and detail-detail, etc) ViewObject where eagerly requeried. With this new approach, page response times have dropped below 1 second.
So, at least in our situaton, this solution seems to work. I'm just wondering what the downside of closing the RowSetIterator is. There must be some drawbacks to this approach, but it seems I can't find any so far. Hopefully some of you can suggest what the danger/drawback is in closing a RowSetIterator.

Answer 1

Shay's question about experience is a good one. If you're not already proficient at UIX then I would choose JSF. If you've done very little J2EE/Java/JSP/HTML development work, you've got a couple of months of ramping up to be able to accomplish much tangible.
I've been working on a project for a couple of months using ADF BC on the backend and JSF/ADF Faces for the View. The enticement was built on the expectation that 10.1.3. would be going into production very soon, and it seems that this is true, from what little hints and clues I can pick up from these tight-mouthed Oracle guys. ;-)
The disadvantage of going that way is that the documentation sucks for doing anything but the most basic, declarative user interface development, especially if you want to use ADF Faces (there's some decent resource out in the world for JSF development, although even that is pretty thin). This is promised to be much improved with the production release.
For the business services development, unless you already know ADF Business Components I strongly recommend grabbing a copy of the Oracle JDeveloper 10g Handbook. It fills in many of the gaps that otherwise leave you at a loss for how to tie the backend pieces together.
Good luck!
Johnny Lee