Some useful Jdev configurations

Here I am listing out some useful configuration for Jdeveloper

How to change the Jdev user home
 - Goto MW_HOME\jdeveloper\jdev\bin\jdev.boot file  and configure the environment var - "JDEV_USER_HOME" for variable - ide.user.dir.var   and set that env var in the OS Environment variables for the user. Alternatively we can configure the ide.user.dir.var with the hard coded directory path. E.g: C:\myworkspace


How to change Jdev PermGen
 - Goto MW_HOME\jdeveloper\jdev\bin\jdev.conf file,
    change the VMOption - AddVMOption  -XX:MaxPermSize=512M (512M is for example. We can
    set the value as per our requirement)

How to change the heap size for JVM being used by jdev:

- Goto MW_HOME\jdeveloper\jdev\bin\ide.conf and change the Xmx and Xms values as per your requirement.

Preferred Scope for UIComponent bindings

ADF Faces has the feature of binding a UI component with a reference in the managed bean by setting the binding attribute of the component in UI code.

E.g. 
<af:selectBooleanCheckbox label="Select" id="sbc1"   binding="#{managedBean.checkBox}"/> 

Here, the scope of managedBean is very important. Logically speaking, since a UI component is available on a page only until it lasts. Once the page is transitioned, the component in the previous page shouldn't be there and has to be garbage collected. In such scenario, if we are referring the UI component by a reference sitting in a managed bean defined at scope higher than the View scope, it can't be garbage collected thereby increasing the memory footprint. So to avoid this, we need to refer the UI component only from managed beans at scopes - View/Request/Backingbean. The request scope and backingbean scope is justified because it lasts until the page is transitioned and response is sent back to client and often we need to execute some logic in the code behind with the help of UI component reference.

Suppose you have a taskflow that has only one page in it. Can you now use the reference in managed bean defined at taskflow scope to bind the UI components in the only page of that taskflow. Well, from memory management perspective its okay as the pageflow scope here is almost equal to backingBean scope or requestScope because a page transition here will always lead to exit of the current taskflow thereby clearing the pageflow scope. But still this is not acceptable. Lets see why it is so.
 
When your application works in a cluster environment in the high-availability mode (actually, this is not the only case) the session with all memory scopes higher than request might be serialized in order to be restored on a different JVM instance. UIComponent (The super class of all ADF/JSF Components)  is not a serializable class, and you are going to get a serialization exception in case of binding components to the long-living managed beans.

So, in a nutshell, the preferred scopes for UI component bindings are - View Scope/BackingBean/RequestScope.

Commit Execution process of ADF Entity objects

When a creation or updation or deletion of a row happens in ADF VO, the corresponding actual  operations happen against the respective underlying entity instance. When a commit is initiated, the entity instance posts the changes to database and commits them. Below are the steps involved in transaction commit process.

Step1: When commit is initiated on the AM that contains the VO on which create/update/delete operations are done, The transaction manager starts the post cycle of all the entity instances which are dirty(either created/updated/deleted).  Below steps are executed for each dirty entity instance.

- Validation of business data is triggered.  (Entity level validations). EntityImpl::validateEntity()
- EntityImpl::postChanges(...) method is invoke which in turn invokes below methods.

• EntityImpl::lock() : Locks the row.    
• EntityImpl::prepareForDML(...) : A pre-notification for preparing rows for posting to DB.        If you need to update some dependency columns or custom history columns then this is the place to add that logic.
• EntityImpl::doDML(...) : Performs INSERT/UPDATE/DELETE processing for the row.

  Once the postChanges of a dirty entity instance is completed, the following methods gets invoked

• EntityImpl::beforeCommit(...) : Reports that a commit operation has initiated
• EntityImpl::afterCommit(...) : Reports that a successful commit operation has occurred