# About the Business Component Fault-in Mechanism

The Business Components for Java framework lets you define Entity Objects (mapping tables to Java classes) and lets you build View Objects using SQL statements over the tables to which Entity Objects are related. The SQL SELECT statement associated with a View Object lets you select just the "slice" of relevant information from the tables related to the Entity Object. You can select all, or only some of the attributes in the underlying Entity Object.

When you create the View Object, you are encouraged to include only the attributes that the client needs to work with. For example, suppose that you are writing a client application that displays a list of 10 attributes in a form which a user can edit. Also suppose that the table associated with the Entity Object, contains a total of 200 attributes. In this case, you can design a View Object that contains only the 10 attributes that will be displayed on the client. Note that one of the attributes must be a primary key. If you use the JDeveloper View Object Wizard to construct the View Object, it will automatically include the primary key.

When the View Object is executed, its SQL statement is sent to the database. This statement will select the 10 attributes including any primary key columns. The framework uses the primary key columns to uniquely identify each Entity Object instance: each instance corresponds to a row in the database table. The Entity Object in its partially populated state (10 attributes populated) is put in the Entity Object cache.

Applications frequently read much more data than they write. So it is important that applications performing reads and lookup only retrieve and cache just the information it needs. In the example described above, only the 10 attributes are retrieved and put in the cache; the remaining 190 attributes referenced by the Entity Object are not. This results in a savings in terms of memory and performance.

If the user on the client enters a value that causes the business logic to ask for the value of one of the excluded 190 attributes, then the framework uses the primary key value to go to the database and retrieve all of the 200 attributes for the row. This is what the framework refers to as "fault-in": the client's attempt to access an excluded attribute causes the Entity Object to retrieve all of the attributes. Fault-in occurs on the Entity Object instance level. After the fault-in, the cache contains one fully populated row which was the result of the fault-in.

When you design a View Object, consider the following:

- Ensure that the View Object's attribute list includes those attributes that are frequently accessed. It must also include the primary keys from the tables corresponding to the Entity Objects on which the View Object was built.

- The Business Components for Java framework allows the client to access attributes that were not included in the View Object's attribute list. However, remember that accessing excluded attributes will cause a fault-in, and the you will incur a memory and performance cost. Too many fault-ins will lower performance significantly. It is important to fine tune the View Object attribute list, particularly for Entity Objects that include many attributes.

## Fault-in Example

The following example, although clearly contrived, illustrates how a request for an excluded attribute can trigger the fault-in mechanism.

Define a table in the database that defines the following employee information: employee number, employee name, job title, hire date, and salary. The table definition would look like this:

    CREATE TABLE ORACLE_EMP
           (EMPNO NUMBER(4) NOT NULL,
            ENAME VARCHAR2(10),
            JOB VARCHAR2(9),
            HIREDATE DATE,
            SAL NUMBER(7,2),
     CONSTRAINT EMP_PRIMARY_KEY PRIMARY KEY (EMPNO));

Use JDeveloper to create a Business Component project. In the wizard, select the `Oracle_EMP` table (this will create an `OracleEmp` Entity Object) and select the View Objects and View Links and Application Module checkboxes. In the wizard, define the following mappings for `OracleEmp`'s attributes:

       EmpNum -- EMPNO
       EmpName -- ENAME
       EmpJob -- JOB
       EmpHireDate -- HIREDATE
       EmpSal -- SAL

When the wizard asks you to select the View Object attributes to map, select the following:

       EmpNum (corresponds to primary key)
       EmpName
       EmpJob

This creates the View Object query:

    SELECT (OE.EMPNO AS EMP_NUM, OE.ENAME AS EMP_NAME, OE.JOB AS EMP_JOB)
    FROM ORACLE_EMP OE;

Where `OE` is the alias for the `ORACLE_EMP` table.

Now suppose that you create business logic that validates salary when the job changes. This logic would be a validation on the setter method of the `Job` attribute (in the `Emp` Entity Object).

      public void setJob(String value) {

          // Retrieve the salary out of the entity.

          // When getSal() is called on the entity the
          // framework faults in all the excluded attributes.
          Object sal = getSal(); // this line causes a fault-in

          setAttributeInternal(JOB, value);
       }

The `getSal()` method will attempt to fetch the value of `Sal` from the Entity cache. However, since `Sal` was excluded from the SELECT statement, it will not be present. In response, the Business Components for Java framework will fault-in the entire row and will partially populate all of the attributes in the Entity cache for that row.