Improving Performance in ADF Applications - Page Load Time in CRUD Forms

This February I was blogging about how to improve performance in Query type forms - Improving Performance in ADF Applications - Page Load Time in Query Forms. It came time to revisit this topic again, and describe performance tuning in CRUD type applications. Especially, because Oracle JDeveloper 11g Release 1 became available this week. In this release runtime performance improved significantly - Oracle ADF 11g Release 1 - Runtime Page Load Performance Improved ! We are able to run our forms against large data sets without any delay, as it was before. In this post I will describe one of potential designes, how CRUD type applications can be implemented, in order to minimize performance overhead completely.

Download sample application - CRUDPerformance.zip, it contains logic I'm describing in this post.

If you open View Object tuning section, you can see there among other options - No Rows (i.e. used only for inserting new rows). This option means, View Object will not generate any Select statements and will not query database:


In other words, main form query will not be executed and form will be opened only for insert mode - page load performance will be optimal because no initial communication with database. That's sounds exactly what we need, however then how use same form for data editing, if we can only insert. Answer is simple - we can do this also. We should keep in mind, that when No Rows option is set, this means MaxFetchSize is set to 0. This means, on runtime when needed we can programatically change it to -1, it will allow to retrieve data from database then using same View Object. I have implemented MaxFetchSize change in Application Module class:


When form will switch from insert to edit mode and back, I will call this method accordingly.

In ViewController, I have used ADF Task Flow with fragments - default activity is Create action Method Call. It create new row and opens form without database query. There is also fragment for data editing:


On runtime it looks like this, form is opened in insert mode without database query:


I can type data and store it to database:


When record is successfully inserted, form is returned back to data insert mode:


User can press Edit button and navigate to data editing mode. When this button is pressed, action method is called where Rollback is invoked in order to remove new empty row and change MaxFetchSize parameter value to query database:


Data editing fragment is opened with Query Criteria on top and it prevents default query execution:


I can put parameter and find newly entered record, can modify it and save changes to database:


When Create button is pressed in this fragment, action method is call as well and it puts View Object into No Rows mode:


Finally, data insert fragment is opened again:


Spanish Summary:

Andrejus en esta entrega, nos brinda un tip para mejorar la performance de los mantenimientos con ADF. Para ello, realiza configuraciones a nivel de View Objects que evitan un acceso innecesario a la base de datos en los procesos de Creación, Actualización y Eliminación de datos.