Many times it will be useful to understand what happens during the commit phase in ADFbc. It is very much useful to know when the validation happens, when the post changes happen etc..

The following sequence happens when a commit is successful.

1. Validation phase : During this phase all the entities which are marked as modified are validated.
2. Post changes phase: This is the phase where changes from the middle tier will be pushed to the database but will not be commited. This phase consists of two things
   
   
   
   • Lock phase: Where each row that has to be updated will be locked in the database.
   • Prepare for DML phase:  This is the place where you can modify the values of any entity attribute,if you want to before the changes are posted.
     
   • Do DML phase: Where the actual dml statement is fired.
   
   
   
3. Commit Phase: When all the above phases are executed without any problem, the commit happens in this phase.

The following are the EntityImpl methods which will be called in the above phases.

• Validation Phase: validateEntity()
• Post changes Phase : postChanges(TransactionEvent e)
• Lock Phase: lock()
• Prepare for DML: prepareForDML(int operation,TransactionEvent e)
  
• Do DML phase: doDML(int operation, TransactionEvent event)
• After Posting is done: donePostingAll(TransactionEvent transactionEvent) 
• Before Commit: beforeCommit(TransactionEvent transactionEvent)
• After Commit: afterCommit(TransactionEvent transactionEvent)

Normally, a shell script is nothing but a series of commands to be executed. Some commands open up a sub shell and will prevent the remaining commands in the script from getting executed..

To run such commands in the sub shell opened by the command use the
-exec option..

For example when you use the ADE commands like

ade useview view_name

a new subshell will be created..In this new sub shell, if you want to run any command, do the following..

Create a new shell script which contains all the commands to be executed in the sub shell ..for example

subshellcommands.sh
------------------------
ade pwv
cd $ADE_VIEW_ROOT/bin
ant -f build.xml build

Now the actual script that contains the ade useview command should be as follows..

mainscript.sh
-------------
ade useview -exec /full/path/of/the/file/subshellcommands.sh view_name

Found a good article which explains the differences between the usage of the EL expressions like
${expr} (immediate) and
#{expr} (deferred)

Here is the link

Here are some of the important points from the article (in case if you don't want to follow the link..

The primary limitation of the JSP EL (expressiongs like ${expr}) is that its expressions are evaluated immediately, meaning that the JSP container immediately parses and resolves the expression when it processes the page and returns a response.

Immediate evaluation is sufficient when a JavaServer Faces page is rendered for the first time. However, after the user enters values into the UI components and submits the page again, those values are converted, validated, and propagated to server-side data objects, and component events are processed. In order to convert data to the proper type, validate it, store it in an external object, and process events in an orderly fashion, the JavaServer Faces life cycle is split into separate phases to handle each of these tasks. Therefore, it must be possible to evaluate expressions at different phases of the life cycle rather than immediately, as is done in JSP technology.

Another problem with the immediate evaluation of expressions is that it is done in read-only mode. JavaServer Faces components need to be able to get data from server-side objects during the rendering phase and set the data in the server-side objects during postback.

Finally, JavaServer Faces components need a way to invoke methods on server-side objects during various stages of the life cycle in order to validate data and handle component events. JSP functions are not sufficient because they can only be used to call static methods defined in a TLD file; they cannot be used to dynamically invoke public methods on objects.

The following piece of code is used to set a dynamic where clause to a view object. It also shows how to set  values to the named bind parameters present in the dynamic where clause.

    public void addWhereClauseWithNamedBindParams(){
        ViewObject vo=this.getEmp1();
       
      
        vo.setWhereClause(null);
       
        vo.setWhereClause("Empno=:eNo");
        vo.defineNamedWhereClauseParam("eNo",new Integer("7369"),null);
        vo.executeQuery();
       
        vo.removeNamedWhereClauseParam("eNo");
        vo.setWhereClause(null);
    }

The following piece of code shows how to add a dynamic where clause to a view object .
It also shows how to set the bind parameters (using the positioning style not the named bind parameters)

    public void addWhereClause(){
        ViewObject vo=this.getEmp1();
       
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
       
        vo.setWhereClause("Empno=:1");
        vo.setWhereClauseParam(0,new Integer("7369"));
        // you can also use the following code to set the positional parameters.
        // vo.setWhereClauseParams(new Object[]{new Integer("7369")});
        //
        // The difference between the two apis is that one explicitly provides
        // the bind parameter position and in the second one the position is implicity
       
        vo.executeQuery();
       
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
    }

Using the "setWhereClauseParam" or "setWhereClauseParams" api's you cannot set the named bind parameters....