Didier's Blog

We already noted a weird tip of the day: "Microwave Safety"
Brian explained on his blog other tips were proposed by the development team, but (unfortunately) never made it.

It seems there was also a contest between the authors of the online help to avoid some keywords.
See f.ex. the topic "What's New in Oracle ADF Business Components":

Either the author of this topic has a bad memory, or ... he won the contest  ;-)

Some customers mention that after a certain period of inactivity, the Application Module pool is completely empty.
This happens even though jbo.ampool.minavailablesize (Minimum Available
Size) is greater than 0.

The reason is that after x milliseconds, we consider an AM instance in the pool as a candidate for removal during
the next resource cleanup regardless of whether it would bring the
number of instances in the pool below jbo.ampool.minavailablesize.

This is specified by parameter jbo.ampool.timetolive (Maximum Instance Time to Live) with has a default of one hour (3600000 milliseconds).
For more details, see Understanding Application Module Pooling Concepts and Configuration Parameters and Topic  29.6.2 Pool Sizing Parameters in the ADF Developer's Guide

Some users report intermittent errors like the following, occurring under heavy load in the Production environment:

oracle.jbo.SQLStmtException:
JBO-27120: SQL error during query execution. Statement: <SQL Statement>
(...)
java.sql.SQLException: Missing IN or OUT parameter at index:: <index number>

or

JBO-27122: SQL error during statement preparation. Statement: <SQL Statement>

or

JBO-30003: The application pool (AppModuleLocal) failed to checkout an application module due to the following exception:
oracle.jbo.JboException: JBO-29000: Unexpected exception caught:
oracle.jbo.common.UnknownSQLTypeException,
msg=JBO-25000: Unknown SQL type: null

These errors are difficult to diagnose as developers cannot reproduce in the Development or Test environments.


There is then a strong suspicion that the problem is related to the Application Module passivation / activation.

To be 100% sure this is the case, you can force it to occur in your Development environment by setting jbo.ampool.doampooling=false (or uncheck the "Enable Application Module Pooling" in your Configuration):




From the ADF Developer's Guide topic "28.3 Controlling the State Management Release Level" ("Note" under 28.3.1 Supported Release Levels):
 "Setting this property [jbo.ampool.doampooling] to false is useful to discover problems in your application logic that might occur when reactivation does occur due to unpredictable load on your system."



If the problem reproduces then, you'll be 100% sure the problem occurs at the reactivation of your Application Module.
Please contact Oracle Support Services then so that a Support Engineer can help you in fixing the problem.

We recommend you to test all your applications in your Development environment with this parameter jbo.ampool.doampooling=false to ensure they are activation-safe, as explained in "28.8 Testing to Ensure Your Application Module is Activation-Safe" of the ADF Developer's Guide.

Forewarned is forarmed...

I explained in a previous post how to simulate the AM (Application Module) passivation / activation.
I got some feedback from customers that it helped in determining the cause of a java.lang.NullPointerException end-users were complaining about from time to time.

We investigated further and found out that the problem was related to information stored in oracle.jbo.Session user data hashtable

Hashtable userdata = getDBTransaction().getSession().getUserData();

The problem is that ADF Business Components do not handle this user data itself during passivation.and it's up to you to write some code in your application if you want to preserve the information across passivation and activation. You can do this by overriding passivateState() and activateState() methods.

For more information, see the ADF Developer's Guide, topics "9.10 How to Store Information About the Current User Session" and  "28.5 Managing Custom User Specific Information"
You can find there an example of code to save User Data at passivation in :"Example 28-7 Passivating and Activating Custom Information in the State Snapshot XML Document"

I've added example # 3 to illustrate how to use an <af:selectBooleanCheckbox> bound to VARCHAR2 or NUMBER Oracle Database columns.
This is performed by creating a transient attribute of type Boolean and redefining its getter and setter methods to 'translate' the ADF Business Components type Boolean to the 'standard' String or Number types that the Oracle Database "understands".
(Boolean is not a valid type in the Oracle Database).

I have been working on a tricky case where the customer had developed a custom DBTransactionFactory, following instructions from the article "Creating and Using a Custom DBTransaction Implementation" from Steve Muench.

It was working fine and the application was correctly using the custom DBTransactionFactory.
However, after customer deployed another application in the same Web Container and also using its own custom DBTransactionFactory, he  noticed that the second application was using the same DBTransactionFactory (same class and same instance) as the first application.

After investigation, development pointed out that TransactionFactory has a MetaObjectManager scope, as shown when executing the following command:

java -cp <JDev_Home>BC4Jlibbc4jmt.jar oracle.jbo.common.PropertyManager

---------------------------------------------------------------
Business Components for Java - System Properties
---------------------------------------------------------------
Properties loaded from following sources, in order:
1. Client environment
2. Applet tags
3. -D flags (appear in System.properties)
4. bc4j.properties file (in current directory)
5. /oracle/jbo/BC4J.properties resource
6. /oracle/jbo/commom.jboserver.properties resource
7. /oracle/jbo/common.Diagnostic.properties resource
8. System defined default
---------------------------------------------------------------
...
TransactionFactory MetaObjectManager (M)public Internal
...
---------------------------------------------------------------

As explained in the JDeveloper online help, topic "Understanding Configuration Property Scopes":

...
You'll see each property is listed with one of the following scopes:

* MetaObjectManager
   Properties at this scope are initialized once per Java VM when the ADF PropertyManager is first initialized.
...
If
you leave any MetaObjectManager-scoped properties in your bc4j.xcfg
files, you will have the undesirable behavior that they will take on
the value specified in the configuration of the first application
module whose pool gets created after the Java VM starts up.
...

We could force each application using its own version of TransactionFactory by adding code to the latter part of each ApplicationModuleImpl.

In Application 1, that should use CustomDatabaseTransactionFactory1, f.ex.:


...

static

{
   oracle.jbo.server.DatabaseTransactionFactory.setFactory(new CustomDatabaseTransactionFactory1());

}

In Application 2, that should use CustomDatabaseTransactionFactory2, f.ex.:

...

static

{
   oracle.jbo.server.DatabaseTransactionFactory.setFactory(new CustomDatabaseTransactionFactory2());

}