ADF Post Changes and PL/SQL Invocation Side Effect

If data will not be commited to the database in the same request - not recommended to use postChanges() method in ADF BC. ADF developers tend to bypass this recommendation, especially when integrating ADF with PL/SQL code and trying to keep temporary data in the database. From my experience, is not safe to use postChanges() method even if database commit is done in the same custom method (read - one request). ADF BC passivation may happen anytime unexpected and then posted data is simply lost. Typically this error is not reproduced in development environment, but only in test or production when there are more concurrent users accessing the system. Good practice - always run your application with Application Module Pooling disabled before sending code to the testing team - this would allow to simulare stress test environment and force ADF BC to switch Application Module pool instances.

I would like to demo most common ADF post changes and PL/SQL invocation side effect with this simple application - PostControlApp.zip. Inside archive you will find SQL file with PL/SQL function for this application - EMPL_SAL_SUM. Function is pretty simple, it calculates total salary for all employees. The idea is to show that after Application Module passivation happens, posted data is lost and total salary is still returned without changes:

There are two custom methods implemented on top of Application Module Implementation class. One method is responsible to post changes and second calls PL/SQL function and returns total salary:

Here is the source code implementation for these two methods:

UI fragment contains two buttons, designed to invoke two custom methods. Total calculated salary value  is displayed visually:

If you decide to run sample application, firstly invoke Show Total Salary button - it will display current sum (0.68M in my case):

Change salary value for one of the employees to be lower - 110 as for example and press Prepare For Update button (this calls postChanges() method):

Method - postChanges() is pushing data to DB, executing DML statement without commiting. Developer tend to think - this is great, we can push data to DB and invoke PL/SQL code over it. Not so fast - keep in mind ADF BC passivation behavior (DB connection from Application Module can be switched at any time and posted data will be lost for the next request):

Invoke Show Total Salary again - you will see a change in calculated total salary (0.67M). This time calculated value was retrieved from PL/SQL function correctly, simply because ADF BC passivation didn't happen:

Disable Application Module pooling - you will get different result:

Change salary value and press Prepare For Update button to invoke postChanges():

This time passivation happens, we can see that from the log:

Calculated total salary value stays the same after refresh - posted data was lost, because of change in database connection:

Resolving Invalid ADF BC Library Import in JDeveloper 11g R2

This week I came across ADF BC library import problem onsite. ADF BC library was very large, around 1000 EO's. EO's were not visible through JDeveloper wizard from consuming project after import. At first I was this is related to library size - too many ADF BC objects, JDeveloper fails to list them through ADF library import. But this proved to be false assumption, when I tested with smaller library. At the end I found there was duplicate definition for EO package path inside consuming project, it was duplicate to the one from ADF library. This was a reason why JDeveloper wizard was not resolving imported ADF BC. I will describe this case in a bit more detail, I believe this might be helpful (JDeveloper version - 11g R2 (11.1.2.x)).

Download working sample application with ADF BC library import - adflibimport.zip.

ADF BC library contains one EO object - com.redsamurai.common.model.entities package:

Project is deployed as ADF library and connected through JDeveloper resource catalog - EO object for Employees is included:

All is correct ay this point. But in my case imported ADF lib JAR file was showing imported package, but content was empty. Exactly as you can see in this screenshot - no content for com.redsamurai.common.model.entities package:

It seems like JDeveloper randomly may register package from imported library inside local Model.jpx ADF BC configuration file. When this happens - there will be duplicate package on class path and no ADF library objects shown in JDeveloper wizards. Its what I had in my case - imported package name was populated as well into local Model.jpx file:

After imported package name entry was removed from local Model.jpx, JDeveloper wizard instantly started to show imported EO object name:

If you will encounter the same situation - no ADF BC objects visible from imported library, make sure to double check local Model.jpx file, may be you will find duplicate entry for package name from imported library.

Proactively Monitoring JDeveloper 11g IDE Heap Memory

There is possibility to monitor during runtime consumed heap and permgen memory by JDeveloper IDE process. It will show consumed memory, also allows to force garbage collection. This can be extremely useful when running JDev on less powerful hardware - developer could force garbage collection, just before entire memory is consumed and JDeveloper is freezing.

This post is based on JDev 11g R2 (but same applies for other JDev 11g versions).

Its fairly easy to enable JDeveloper 11g Heap Memory Monitor, add this property to jdev.conf file (located under JDEV_INSTALL/jdev/bin/ folder) and restart IDE:

AddVMOption -DMainWindow.MemoryMonitorOn=true

You will see in the IDE lower right corner - heap and permgen memory statistics will be available, along with garbage collector button:

I did a quick test - opened one JSPX file in Designer mode. Heap memory consumption increased from 90M to 256M, PermGen from 82M to 124M:

Next I invoked garbage collection process by clicking recycle bin icon:

Heap memory usage instantly dropped to 176M:

Don't worry, memory consumption is quite stable and not growing over time. I was trying to open multiple complex pages, close and open again - IDE was acquiring and then after some time releasing memory. It was consuming around 300M - 400M heap and 200M PermGen memory, when working with complex pages/fragments and ADF BC wizards:

Maximum range for heap memory is set in ide.conf file (located under JDEV_INSTALL/ide/bin/ folder). Default value of 800M is usually enough for ADF development: