ADF BC Performance - View Object Instance Lazy Activation

ADF BC is a great framework to manage data, but one thing it does really smart - ADF BC View Object instance lazy activation. You must know by now - passivation/activation events in ADF BC are relatively expensive in terms of performance. Especially expensive is activation event, as during this event View Object instance is re-constructed and data is re-fetched. However, it is not as bad as it sounds - it doesn't activate all View Object instances from Application Module together. Only View Object instances referenced from current Page Definition are activated. This means, if user was working with 10 screens, before passivation event happened - during activation event, only View Object instances from current screen will be activated. View Object instances from other screens will be activated, when actual screen will be accessed. Good news - you don't need to tune anything for this, this is how it works by default.

We track ADF BC performance with Red Samurai Performance Audit Tool - Update for Red Samurai Performance Audit Tool - v 2.4. Slow activations are recorded as well, this allows to measure activation event impact to your ADF application performance.

To prove lazy View Object instance activation scenario, I have developed sample application - AMStatisticsApp_v2.zip. Application Module is set to support only one referenced instance, this means we can force passivation/activation events with two Web sessions running in parallel:

AM data model contains two different View Object instances, this is to check if both will be activated on the same time:

Generic VO implementation class overrides activateCurrentRow method, to record activation event for View Object instance. Red Samurai Performance Audit Tool overrides the same method, to log slow activation, as this method is called at the end of activation event - when all records for the VO rowset were fetched:

On Task Flow side, I have created two fragments (each for VO instance from AM data model):

Each fragment is mapped with its own Page Definition file, this means each fragment have its own bindings:

To test provided sample application, make sure to set FINEST logging level for Generic VO implementation class:

Open application, first fragment with Employees data will be loaded:

Go to Departments fragment, to load Departments VO instance and navigate back to Employees:

Open second browser session, without closing the first one:

Referenced Pool Size is set to 1, this means AM instance from first session will be passivated. Now go back to the first session browser and change row selection - you will see in the log activation event for the Employees VO instance only:

Departments VO instance was not activated yet, as it belong to different Page Definition, it will be activated lazily - when data from second Page Definition will be loaded. Navigate to the Departments fragment, mapped with the second Page Definition:

Only when you navigate to Departments, and load data from Departments Page Definition - it activates Departments View Object instance - see new message printed in the log. This is quite smart and good functionality in terms of activation performance:

Update For: Recording ADF BC View Object Instance Activation Time

You may have seen my previous blog post - Recording ADF BC View Object Instance Activation Time. This post describes how to track activation events time for individual VO's, so you can understand how much activation process may slow down your ADF system runtime performance. I was testing it in stress test environment and discovered issue related to activation start time logging - start time variable value was lost in some cases and set as NULL. Today post describes a fix, activation time is logged more accurate with information from ADF BC AMStatistics helper utility class.

Here you can download updated sample application - stresstest_v6.zip. This sample logs activation time for each individual VO, including AM and VO names, number of fetched rows and activation label (this helps to group activation events from individual VO's and understand total exceeded time per AM activation event for all VO's):

As you can see, for the second VO - same activation label is assigned, this is because both VO's were activated during the same AM activation event:

VO with longest activation time reported in the same AM activation event group, always is activated last. Longest time represent total time for AM activation in the given activation event.

There are two VO activated, because there are two VO's included into ADF UI page - Jobs and Departments, both of them are activated (AM pool is switched off for test purpose):

Instead of logging AM activation start time in the separate method and keeping start time in VO class variable, as it was before - now I'm using only single method activateCurrentRow and within this method getting AM start time from AMStatistics class. AM start time represents time when AM was started during current activation event. As AM always starts first before any VO is activated, we can use this info in our method:

ADF BC Passivation/Activation and SQL Execution Tuning

Passivation/activation in ADF BC is designed to keep temporary user data across requests, when there are more online users than application pool can handle. If you are new to this, please read from Oracle developer guide - 40 Application State Management. There is added cost to passivation/activation - additional SQL execution. During activation event, its not only temporary data gets initialized - but complete VO SQL gets executed again. This means system could suffer significant performance issues, if there are lots of passivation/activation events happening. In order to avoid frequent passivation/activation, make sure to tune referenced pool size properly for your environment - Stress Testing Oracle ADF BC Applications - Passivation and Activation.

This post demonstrates additional SQL execution during activation event. Download sample application - ActivationSQLApp_v2.zip.

Form is loaded for the first time:

One SQL execution happens as it should:

We are running test with AM pooling disabled, this allows to simulate stress test environment and trigger activation/passivation events:

With AM pool disabled, without closing screen, press Next button in the form - this will navigate to the next record:

SQL will execute one more time:

From the detail log, we can see that SQL execution event is logged as well, when there is activation event:

During normal scenarios, SQL is executed once and data stays in memory. Keep attention, how often passivation/activation happens in your system - this can affect performance significantly.