Monday Jul 30, 2012

There are
cases where everything works well during development and testing but we face a
lot of exceptions in the production environment. In most of the cases, this
strange behavior will be related to wrong transient attribute usage, transient
attribute whose value is not passivated and then it is lost after activation. In
production, when there will be high workload and many concurrent users, ADF
will start to passivate Application Module instances and we will face a problem.
Production environment can be simulated by disabling Application Module
Pooling.

Disabling AM PoolingFor disabling
the AM pooling, checkout the AM and right click on it, select Configuration and then select Edit. Click on the “Pooling and Scalability” tab and disable the “Enable Application Module Pooling” check box.

Passivation of Instance Variable in
AMInstances
variables are not passivated by the framework. Framework recommends not using
any instance variables by the developer. If at all developer badly needs
instance variables in any of the Impl class, Developer needs to explicitly
override 'passivateState' and 'activateState' methods(in corresponding
Impl) to passivate and activate those variables.

AFStretchWidth is a marker style class that will declaratively stretch a component
horizontally in a wide flowing container. This style class should be
used instead of attempting to use a percentage width as an inlineStyle
width to stretch a component horizontally.

I copied and pasted the query on SQL worksheet, replaced :Bind_PIdwith a valid id, and executed the query. The query worked alright, implying the query was alright. I tried to connect to different DBs but the issue persisted, meaning it was not a DB issue either.

Finally, the root cause was found to be in the concerned VO; one of the bind variables (say Bind_TId) was marked "Required". De-selecting the Required check-box resolved the issue.

In retrospect, the issue looks to be rather straight-forward. However, the error message is not very helpful, if not misleading. Besides, it's counter-intuitive to think that a bind variable which is not being used in a query can cause error while statement preparation. The other bind variable - Bind_TId - was being used in other view criteria, not the view criteria involved in the given query. Still, it was required.