Performance tuning : Fault-in behavior in ADF

Well these days I got some interest in performance improvements in ADF applications.

So, here is an interesting term 'fault-in'. Before, I tell what it is the thumb rule is "Try to avoid it.".

Normally, when you build your Model or business components you start with building entity objects. On an entity object you build one or more view depending upon the UI requirements.

If you go with default options of creating an updatable view object based on an entity object you get a sql query which is selecting all the entity attributes with no where clause which is called 'Deafult VO query'. So, say you have an entity object EmpEO based on an employee table with selected attributes empId, empName, empSalary and mgrId then you will get something like

SELECT EmpEO.empId, EmpEO.empName, EmpEO.emoSalary, EmpEO.mgrId

FROM employee

However, in real life we create VOs depending upon the UI page requirements. So, say we create VO choosing only empId, empName and empSalary. While creating UI say it is just required to show empId and empSalary from the VO instance. On running the page, which has a VO instance of this VO as a table, ADF framework queries all the rows from the employee table and create entity instances one per row having information about empId, and empSalary. It will not populate empName and mgrId from DB. The VO instance will have pointer for each vo instance row to the actual EO instance having data.

This is pretty smart as most of the times you might be only viewing data and in that case it saves time and memory by not populating entity instances with data you don't need. Now, imagine there is a update page based on this vo instance where you try to update the emp record with id 486. In the entity object you define a validation rule that empSalary of the employee being updated should not be higher than the salary of any of the employee under his manager. So, here fault-in comes to the picture. As mgrId is mentioned in the validation rule which is missing from VO definition so while checking for this validation on record commit, framework will fire the default VO query and hence will populate all the missing EO attribute information from DB for that row . That could cause performance overhead at run time. It may be fine for a case where there is just one missing attribute and your entity is based on a few attribute based table. But in a scenario where say your entity has 100 or more attributes in that case default VO query may be big performance overhead. Situation could be worse when some of the attributes may be of type CLOBs or BLOBs.

To avoid fault-in you can look up for such cases and add such attributes to your VO. This way, while executing the VO query for the first time it will automatically populate such attributes as well in the entity instances.

Another way is slicing your entity object into multiple entity objects and creating composite VOs. For example say you have a Emp table with 30 columns some of being CLOB and BLOB types or very less used. So, you can create two Entity Objects one with mostly used columns and another with rest of the attributes. Depending upon your business requirements you can create VOs either on just one of the two EOs or a composite VO based on both the EOs.