Application Module - Commit Transactions

Hi, I have implemented a way to identify a foreign key, in the view object edit page, and put a lov beside it. When the user puts some invalid value in the foreign key field it validates the field and back to the edit page. But now I want to put another button beside the foreign key that allow the user to insert an entity of the foreign key view object type.
For example:
I have a sales page that have the following fields: code_sales, total_price, prod_id(foreign key), date... The user can choose a product from the LOV beside it or puts a prod_id directly on the field . Once the user has putted a invalid prod_id(a prod_id that does not exist on the product table) the system alerts the user indicating what field has generated the error and the user has the option to insert a new product or choose another product. If the user has choosen to insert a new product the system opens the product view object edit page and inserserts a new product. The problem is that when I insert and commit the product information it generates an error becouse the sales row is not valid. How can I insert the product in a independent way. Maybe I should open a new Application Module.
Please, what can I do?
Thanks in advance,
Junior

It does not work. I have tryed to insert the row in the Product's VO but the Product I have just inserted does not appears int the Product's LOV.
Here is the code I have tryed:
<jbo:Row id="myrowNew" datasource="ds" rowkeyparam="jboRowKey" action="updateNewRow" />
<%
TmsProductViewRowImpl viewRowImpl = (TmsProductViewRowImpl)myrowNew;
TmsProductViewImpl vo = (TmsProductViewImpl) viewRowImpl.getViewObject();
vo.insertRow(myrowNew);
%>Junior:
The above code looks to me that you are inserting row back in the Product VO, not Products LOV VO. If I undestand your app correctly, we have two VOs: ProductVO which you're using to create a new Product and ProductLOVVO which you're using to build the LOV.
Your myrowNew is one created and inserted by ProductVO. Your "vo.insertRow(myrowNew)" will end up inserting myrowNew twice into ProductVO (which you wouldn't want). Instead, you want to insert myrowNew into ProductLOVVO. Assuming that named of the Product LOV VO is ProductLOVVO, you would want to change the code snippet above to something like the following:
<jbo:Row id="myrowNew" datasource="ds" rowkeyparam="jboRowKey" action="updateNewRow" />
<%
    TmsProductViewRowImpl viewRowImpl = (TmsProductViewRowImpl)myrowNew;
    // Replace "ProductLOVVO" with the appropriate Product LOV VO's name
    ViewObject productLOVVO = viewRowImpl.getViewObject().getApplicationModule().findViewObject("ProductLOVVO");
    productLOVVO.insertRow(myrowNew);
%>Thanks.
Sung

Similar Messages

  • Nested Application Module - commit behavior

    Guys,
    I have ADF BC in the following hierarchial manner.
    AM1
    -VO1
    -VO2
    -AM2 (nested AM)
    Assume that there are pending transactions on both AM1 and AM2.
    what is the behaviour for the follwing?
    Q1 . Issuing commit on AM1, will it commit AM2 also?
    Q2 . Issuing commit on AM2, will it alone commit?
    Edited by: Dev on Apr 19, 2011 12:00 PM

    ADF distinguish between root application module and nested application modules. A root app module has no parent whereas an nested app module has a parent. A root app module holds the transaction (and only the root app module). Nested app module share the transaction of the root app module (they are nested in).
    So Q1: yes and Q2: no.
    Read 9.4.2 here http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/bcservices.htm#sm0229 fro more info.
    Timo

  • Rename Application Module Woes

    I've written a series of web pages (maybe 10 or so) with about 30+ entities, associations, views, and view associations. I'd like to organize these in some fashion as this is only "part1" of a 4 part endeavor.
    I grouped entities and associations together into one package, then views and view links into another package. I was thinking of placing each part's entities and views/view links into their own packages.
    Then, I wanted to RENAME the application module from the standard AppModule to PFAppModule.
    Issue#1: When I did this and attempted to run the application, I received an error that the configuration AppModuleLocal could not be found. I then edited the application modules's configuration, renaming it from PFAppModuleLocal to AppModuleLocal.
    Issue#2: Well, if I drag any items from the Data Control Palette onto the screens, I get a new entry PFAppModuleDataControl. So I have two data control entries in DataBindings.cpx. Is this an issue?
    Issue#3: Even if I rename the DATA_CONTROL_PALETTE to it's original name: AppModuleDataControl, when I drag and drop objects from it, I get another new "data control name" in DataBindings.cpx called AppModuleDataControl1. Is this an issue?
    I guess I thought renaming a module would "propogate" the changes to the appropriate places.
    Am I simply wasting time?
    I'd like to create some more appmodule's now for each subsystem of the web application. Is this the right approach considering an application module is considered "task specific"?
    Any help/assistance/advice will be greatly appreciated.
    Thanks.

    The application module handles the session. You can read more about application modules and transactions in the online documentation, under
    User guides
    Developing business components
    Understanding transactions
    Blaise

  • Commit on one application module also commits the other

    Jdev 11.1.1.4
    I have a fusion ADF application where I have defined two Data Controls.
    One is called AppModuleDatacontrol and the other AppModuleWSDataControl.
    I do this in order to be able to commit DML made on one Data Control independently of the other.
    The problem is that when a do something like:
    AppModuleWSImpl am=(AppModuleWSImpl)Util.getApplicationModule("AppModuleWSDataControl");
    am.getTransaction().commit();
    Errors on VO of AppModuleDataControl are raised. They were not expected to be raised !
    I have activated ADF logs and just after executing
    AppModuleWSImpl am=(AppModuleWSImpl)Util.getApplicationModule("AppModuleWSDataControl");
    and before executing the commit I get:
    <BindingContext> <findDataControl> [4147] INFO: no refreshRegion, skipping cpx codebase lookup on AppModuleWSDataControl
    <BindingContext> <put> [4148] BindingContext.put( AppModuleWSDataControl@edu_esade_view_DataBindings_cpx, oracle.jbo.uicli.binding.JUApplication )
    <PropertyManager> <loadProperty> [4149] WARNING: Property jbo.maxpoolcookieageset to null
    <PropertyManager> <loadProperty> [4150] Skipping empty Property jbo.maxpoolcookieage from null
    <BindingContext> <put> [4151] BindingContext.put( AppModuleWSDataControl@edu_esade_view_DataBindings_cpx, oracle.jbo.uicli.binding.JUApplication )
    <BindingContext> <put> [4152] BindingContext.put( AppModuleWSDataControl@edu_esade_view_DataBindings_cpx, oracle.jbo.uicli.binding.JUApplication )
    <DebugDiagnostic> <print> [4153] DBG: DataControl:Looking for :_adf_dc_user_params_key_
    <DebugDiagnostic> <print> [4154] DBG: DataControl:Looking for :_adf_dc_user_params_key_
    <ADFLogger> <begin> Create nested Application Module
    I don't know if "Create nested Application Module" is important but I don't want this AppModule to be nested of the other. I want them to be completly independent in order to achieve independance of the commit actions.
    Any help ?

    "1.Defining all BTF as "No controller transaction" I can assume both AppModule will always work with different transactions "
    As long as they're defined as separate root AMs and you've used the <No Controller Transaction> option they will work with different db connections, therefore different transactions too.
    "and one transaction in one AppModule will persist trough pages"
    Within scope of one BTF yes. In scope of chained BTFs that's dependent on the BTF data control scope option. If you set that to isolated, each instance of a BTF will spawn a new instance of the AM in question (and new connections/transactions with the database). If you use shared, 1 instance of the AM will be shared (1 connection/transaction).
    "2.What impact can have this in reusing BTF ? I have a jsf page reusing the same task flow in two regions. The taskflow performs some initialization. Will the regions undesirably interact one with the other ?"
    That depends on the data control scope option as specified above. If you want them to be independent, use the isolated data control scope options on the BTF.
    Consider reading the ADF Task Flow Transaction Fundamentals paper on this website for more information: http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adfarchitect-1639592.html
    CM.

  • Transaction Management for Nested Application Module

    Hi
    I'm using Jdev 11.1.2.0
    I am having nested Application Module. In that I want to separate view object data need to commit without commit the root application module view object.
    Is it possible. Kindly reply me.

    No, the root application module controls the transaction of all need application modules. A commit will commit all changes together. You have to use different root application modules for this.
    Timo

  • Application Module's "query-on-commit"  flag

    Hi All,
    Can you please guide how to set Application Module's "query-on-commit" flag as on/off.

    You'll want to create a method in your application module class that will expose your reporting functionality. You can do this by:
    1. Selecting your AppModule.
    2. Opening AppModuleImpl.java
    3. Creating a method to expose the necessary reporting services.
    4. You'll then need to make this method accessible by opening AppModule editor and clicking on "Client Interface". Shuttle your method to the "Selected" side.
    In the method you create in AppModule.java, pass the module (this) into your report class. You can then perform any actions you with such as querying VO's, updating, etc.
    Finally, for your view/controller layer you'll want to call the newly added methods in your AppModule class instead of calling your reporting classes directly. This will make your code cleaner and easier to maintain as well and also control (encapulate) the reporting services you want to expose to others.
    Hope that helps.

  • How to commit only 1 EO out of 2 in Application Module

    Hi All,
    I am working on Jdeveloper 11.1.1.5.
    Now i have one Application Module , two EO's :- EmployeesEO and DepartmentEO and individual VO's for them. And i have two pages.
    Each of the page, i am showing both the VO'S , like Employee Data and Department Data which is updateable.
    But for the particular page , i need to commit only for the one EO.
    Like if page 1 is there, then when i use the Commit Operation then it should commit only the Employee Data and if i have Page 2 then when i use the commit operation then it should commit only the Department Data.
    Kindly Suggest!!
    Regards,
    Shah

    I'm not sure, but...
    For an entity that does not want to be commited, before commit() call, try to do following:
        getDbTransaction().removeTransactinListener(this);
        getDbTransaction().removeTransactionPostListener(this);
        // after commit(), addTransactionPostListener(...);..or.. you can play with EntityImpl.setPostedToDB()

  • Application Module holds the DB Connection till we commit?

    Hi All,
    Jdeveloper :- 11.1.1.5
    As in my business scenario ,i have an EO and VO and there AM.In VO we have a bind variable which is nothing but the task Id.On Page Load i pass the bind variable to the VO and fetch the data onto the page.As user update the data onto the page and then when he press submit, we actually calls the stored procedure which finally updates the data in the table for the same task id.
    But the problem is , when i am fetching the data from the table using AM,it actually creates a connection with the database but it doesn't release the connection.
    Is there any way where we fetch the data from the table using AM and then close or release the connection so that while submitting tha data to the table using stored proc will not get the locked row.
    Please suggest!!!

    Have you set up the application module to use optimistic locking?
    This mode should hole the lock only during update of the row.
    I don't think the problem is tied to the connection pool. An application module holds on to the jdbc connection until it gets released from the application module pool. This only happens is a application module is not used for a configurable idle time (one of the pooling parameters). If you app releases an application module the module is put back into the application module pool for resuse and holds the connection.
    Timo

  • HOWTO: Using a BC4J Application Module in an Stateless EJB Session Bean

    HOWTO: Using a BC4J Application Module in an Stateless EJB Session Bean
    by Steve Muench
    Overview
    BC4J provides automatic facilities for deploying any application module as a stateful EJB session bean. If you want to leverage the features of your BC4J application module from a stateless EJB session bean, it's not automatic but it is straightforward to implement. This howto article explains the details.
    For our example, we will create a stateless EJB session bean that uses a container-managed transaction. To keep things simple, let's assume the session bean has a single public method on its remote interface named createDepartment() with the following signature:
    public void createDepartment(int id, String name, String loc) throws AppException
    AppException is an example of an application-specific exception that our method will throw if any problems arise during its execution.The goal of this article is to illustrate how to use the BC4J application module named com.example.hr.HRApp as part of the implementation of this createDepartment method on our stateless enterprise bean. Let's assume that the HRApp application module has a view object member named Departments, based on the com.example.hr.DeptView view object, based on the familiar DEPT table and related to the com.example.hr.Dept entity object so our view can be updateable.
    Creating the Stateless Session Bean
    We can start by using the JDeveloper Enterprise Bean wizard to create a new stateless session bean called StatelessSampleEJB implemented by:[list][*]com.example.StatelessSampleEJBBean (Bean class)[*]com.example.StatelessSampleEJBHome (Home interface)[*]com.example.StatelessSampleEJB (Remote interface)[list]
    We then use the EJB Class Editor to add the createDepartment method to the remote interface of StatelessSampleEJB with the signature above. We edit the remote interface to make sure that it also reflects that the createDepartment method thows the AppException like this:
    package com.example;
    import javax.ejb.EJBObject;
    import java.rmi.RemoteException;
    public interface StatelessSampleEJB extends EJBObject {
      void createDepartment(int id, String name, String loc)
      throws RemoteException,AppException;
    }Before we start adding BC4J into the picture for our implementation, our StatelessSampleEJBBean class looks like this:
    package com.example;
    import javax.ejb.SessionBean;
    import javax.ejb.SessionContext;
    public class StatelessSampleEJBBean implements SessionBean {
      public void ejbCreate(){}
      public void ejbActivate(){}
      public void ejbPassivate(){}
      public void ejbRemove(){}
      public void setSessionContext(SessionContext ctx){
      public void createDepartment(int id, String name, String loc) 
      throws AppException {
        // TODO: Implement method here
    }We can double-click on the ejb-jar.xml file in our project to see the XML deployment descriptor for the bean we just created:
    <ejb-jar>
       <enterprise-beans>
          <session>
             <description>Session Bean ( Stateless )</description>
             <display-name>StatelessSampleEJB</display-name>
             <ejb-name>StatelessSampleEJB</ejb-name>
             <home>com.example.StatelessSampleEJBHome</home>
             <remote>com.example.StatelessSampleEJB</remote>
             <ejb-class>com.example.StatelessSampleEJBBean</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
          </session>
       </enterprise-beans>
    </ejb-jar>We need to add the extra <assembly-descriptor> section in this file to indicate that the createDepartment method will require a transaction. After this edit, the ejb-jar.xml file looks like this:
    <ejb-jar>
       <enterprise-beans>
          <session>
             <description>Session Bean ( Stateless )</description>
             <display-name>StatelessSampleEJB</display-name>
             <ejb-name>StatelessSampleEJB</ejb-name>
             <home>com.example.StatelessSampleEJBHome</home>
             <remote>com.example.StatelessSampleEJB</remote>
             <ejb-class>com.example.StatelessSampleEJBBean</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
          </session>
       </enterprise-beans>
       <assembly-descriptor>
          <container-transaction>
             <method>
                <ejb-name>StatelessSampleEJB</ejb-name>
                <method-name>createDepartment</method-name>
                <method-params>
                   <method-param>int</method-param>
                   <method-param>java.lang.String</method-param>
                   <method-param>java.lang.String</method-param>
                </method-params>
             </method>
             <trans-attribute>Required</trans-attribute>
          </container-transaction>
       </assembly-descriptor>
    </ejb-jar>
    Aggregating a BC4J Application Module
    With the EJB aspects of our bean setup, we can proceed to implementing the BC4J application module aggregation.
    The first thing we do is add private variables to hold the EJB SessionContext and the instance of the aggregated BC4J ApplicationModule, like this:
    // Place to hold onto the aggregated appmodule instance
    transient private ApplicationModule _am  = null;
    // Remember the SessionContext that the EJB container provides us
    private           SessionContext    _ctx = null;and we modify the default, empty implementation of the setSessionContext() method to remember the session context like this:
    public void setSessionContext(SessionContext ctx){ _ctx = ctx; }We add additional constants that hold the names of the J2EE datasource that we want BC4J to use, as well as the fully-qualified name of the BC4J application module that we'll be aggregating:
    // JNDI resource name for the J2EE datasource to use
    private static final String DATASOURCE = "jdbc/OracleCoreDS";
    // Fully-qualified BC4J application module name to aggregate
    private static final String APPMODNAME = "com.example.hr.HRApp";We expand the now-empty ejbCreate() and ejbRemove() methods to create and destory the aggregated instance of the BC4J application module that we'll use for the lifetime of the stateless session bean. When we're done, ejbCreate() it looks like this:
    public void ejbCreate() throws CreateException {
      try {
        // Setup a hashtable of environment parameters for JNDI initial context
        Hashtable env = new Hashtable();
        env.put(JboContext.INITIAL_CONTEXT_FACTORY,JboContext.JBO_CONTEXT_FACTORY);
        // NOTE: we want to use the BC4J app module in local mode as a simple Java class!
        env.put(JboContext.DEPLOY_PLATFORM, JboContext.PLATFORM_LOCAL);
        env.put(PropertyConstants.INTERNAL_CONNECTION_PARAMS,DATASOURCE);
        // Create an initial context, using this hashtable of environment params
        InitialContext ic = new InitialContext(env);
        // Lookup a home interface for the application module
        ApplicationModuleHome home = (ApplicationModuleHome)ic.lookup(APPMODNAME);
        // Using the home, create the instance of the appmodule we'll use
        _am = home.create();
        // Register the BC4J factory to handle EJB container-managed transactions
        registerContainerManagedTransactionHandlerFactory();
      catch(Exception ex) {
         ex.printStackTrace();
        throw new CreateException(ex.getMessage());
    }and ejbRemove() looks like this:
    public void ejbRemove() {
      try {
        // Cleanup any appmodule resources before getting shutdown
        _am.remove();
      catch(JboException ex) { /* Ignore */ }
    }The helper method named reigsterContainerManagedTransactionHandlerFactory() looks like this:
    private void registerContainerManagedTransactionHandlerFactory() {
      SessionImpl session = (SessionImpl)_am.getSession();
      session.setTransactionHandlerFactory(
        new TransactionHandlerFactory() {
          public TransactionHandler  createTransactionHandler() {
            return new ContainerManagedTxnHandlerImpl();
          public JTATransactionHandler createJTATransactionHandler() {
            return new ContainerManagedTxnHandlerImpl();
    }The last detail is to use the BC4J appmodule to implement the createDepartment() method. It ends up looking like this:
    public void createDepartment(int id, String name, String loc)
    throws AppException {
      try {
        // Connect the AM to the datasource we want to use for the duration
        // of this single method call.
        _am.getTransaction().connectToDataSource(null,DATASOURCE,false);
        // Use the "Departments" view object member of this AM
        ViewObject departments = _am.findViewObject("Departments");
        // Create a new row in this view object.
        Row newDept = departments.createRow();
        // Populate the attributes from the parameter arguments.
        newDept.setAttribute("Deptno", new Number(id));
        newDept.setAttribute("Dname", name);
        newDept.setAttribute("Loc", loc);
        // Add the new row to the view object's default rowset
        departments.insertRow(newDept);
        // Post all changes in the AM, but we don't commit them. The EJB
        // container managed transaction handles the commit.
        _am.getTransaction().postChanges();
      catch(JboException ex) {
        // To be good EJB Container-Managed Transaction "citizens" we have
        // to mark the transaction as needing a rollback if there are problems
        _ctx.setRollbackOnly();
        throw new AppException("Error creating dept "+ id +"\n"+ex.getMessage());
      finally {
        try {
          // Disconnect the AM from the datasource we're using
          _am.getTransaction().disconnect();
        catch(Exception ex) { /* Ignore */ }
    Building a Test Client
    With the EJB-Tier work done, we can build a sample client program to test this new stateless EJB Session Bean by selecting the bean in the Oracle9i JDeveloper IDE and choosing "Create Sample Java Client" from the right-mouse menu.
    When the "Sample EJB Client Details" dialog appears, we take the defaults of connecting to embedded OC4J container. Clicking the (OK) button generates the following test class:
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import com.example.StatelessSampleEJB;
    import com.example.StatelessSampleEJBHome;
    public class SampleStatelessSampleEJBClient {
      public static void main(String [] args) {
        SampleStatelessSampleEJBClient sampleStatelessSampleEJBClient =
           new SampleStatelessSampleEJBClient();
        try {
          Hashtable env = new Hashtable();
          env.put(Context.INITIAL_CONTEXT_FACTORY,
                  "com.evermind.server.rmi.RMIInitialContextFactory");
          env.put(Context.SECURITY_PRINCIPAL, "admin");
          env.put(Context.SECURITY_CREDENTIALS, "welcome");
          env.put(Context.PROVIDER_URL,
                  "ormi://localhost:23891/current-workspace-app");
          Context ctx = new InitialContext(env);
          StatelessSampleEJBHome statelessSampleEJBHome =
               (StatelessSampleEJBHome)ctx.lookup("StatelessSampleEJB");
          StatelessSampleEJB statelessSampleEJB;
          // Use one of the create() methods below to create a new instance
          // statelessSampleEJB = statelessSampleEJBHome.create();
          // Call any of the Remote methods below to access the EJB
          // statelessSampleEJB.createDepartment( int id, java.lang.String name, java.lang.String loc );
        catch(Throwable ex) {
          ex.printStackTrace();
    }We uncomment the call to the create() method and add a few calls to the createDepartment() method so that the body of the test program now looks like this:
    // Use one of the create() methods below to create a new instance
    statelessSampleEJB = statelessSampleEJBHome.create();
    // Call any of the Remote methods below to access the EJB
    statelessSampleEJB.createDepartment( 13, "Test1","Loc1");
    System.out.println("Created department 13");
    statelessSampleEJB.createDepartment( 14, "Test2","Loc2");
    System.out.println("Created department 14");
    try {
      // Try setting a department id that is too large!
      statelessSampleEJB.createDepartment( 23456, "Test3","Loc3");
    catch (AppException ax) {
      System.err.println("AppException: "+ax.getMessage());
    }Before we can successfully run our SampleStatelessSampleEJBClient we need to first run the EJB bean that the client will try to connect to. Since Oracle9i JDeveloper supports local running and debugging of the EJB-Tier without doing through a full J2EE deployment step, to accomplish this prerequisite step we just need to right-mouse on the StatelessSampleEJB node in the System Navigator and select "Run". This starts up the embedded OC4J instance and runs the EJB right out of the current out path.Finally, we can run the SampleStatelessSampleEJBClient, and see the output of the test program in the JDeveloper log window:
    Created department 13
    Created department 14
    AppException: Error creating dept 23456
    JBO-27010: Attribute set with value 23456 for Deptno in Dept has invalid precision/scale
    Troubleshooting
    One error that might arise while running the example is that the database connection information in your data-sources.xml for the jdbc/OracleCoreDS datasource does not correspond to the database you are trying to test against. If this happens, then double-check the file .\jdev\system\oc4j-config\data-sources.xml under the JDeveloper installation home directory to make sure that the url value provided is what you expect. For example, to work against a local Oracle database running on your current machine, listening on port 1521, with SID of ORCL, you would edit this file to have an entry like this for jdbc/OracleCoreDS :
    <data-source
        class="com.evermind.sql.DriverManagerDataSource"
        name="OracleDS"
        location="jdbc/OracleCoreDS"
        xa-location="jdbc/xa/OracleXADS"
        ejb-location="jdbc/OracleDS"
        connection-driver="oracle.jdbc.driver.OracleDriver"
        username="scott"
        password="tiger"
        url="jdbc:oracle:thin:@localhost:1521:ORCL"
        inactivity-timeout="30"
    />This is the data-sources.xml file that gets used by the embedded OC4J instance running in JDeveloper.
    Conclusion
    Hopefully this article has illustrated that it is straightforward to utilize the full power of BC4J in local mode as part of your EJB Stateless Session Beans using container-managed transaction. This example illustrated a single createDepartment method in the enterprise bean, but by replicating the application module interaction code that we've illustrated in createDepartment, any number of methods in your stateless session bean can use the aggregated application module instance created in the ejbCreate() method.
    Code Listing
    The full code listing for the SampleStatelessEJB bean implementation class looks like this:
    * StatelessSampleEJB
    * Illustrates how to use an aggregated BC4J application module
    * in local mode as part of the implementation of a stateless
    * EJB session bean using container-managed transaction.
    * HISTORY
    * smuench/dmutreja 14-FEB-2002 Created
    package com.example;
    import oracle.jbo.*;
    import oracle.jbo.server.*;
    import javax.ejb.*;
    import oracle.jbo.domain.Number;
    import oracle.jbo.common.PropertyConstants;
    import java.util.Hashtable;
    import javax.naming.InitialContext;
    import oracle.jbo.server.ejb.ContainerManagedTxnHandlerImpl;
    public class StatelessSampleEJBBean implements SessionBean {
      // JNDI resource name for the J2EE datasource to use
      private static final String DATASOURCE = "jdbc/OracleCoreDS";
      // Fully-qualified BC4J application module name to aggregate
      private static final String APPMODNAME = "com.example.hr.HRApp";
      // Place to hold onto the aggregated appmodule instance
      transient private ApplicationModule _am  = null;
      // Remember the SessionContext that the EJB container provides us
      private           SessionContext    _ctx = null;
      public void ejbCreate() throws CreateException {
        try {
          // Setup a hashtable of environment parameters for JNDI initial context
          Hashtable env = new Hashtable();
          env.put(JboContext.INITIAL_CONTEXT_FACTORY,JboContext.JBO_CONTEXT_FACTORY);
          env.put(JboContext.DEPLOY_PLATFORM, JboContext.PLATFORM_LOCAL);
          env.put(PropertyConstants.INTERNAL_CONNECTION_PARAMS,DATASOURCE);
          // Create an initial context, using this hashtable of environment params
          InitialContext ic = new InitialContext(env);
          // Lookup a home interface for the application module
          ApplicationModuleHome home = (ApplicationModuleHome)ic.lookup(APPMODNAME);
          // Using the home, create the instance of the appmodule we'll use
          _am = home.create();
          // Register the BC4J factory to handle EJB container-managed transactions
          registerContainerManagedTransactionHandlerFactory();
        catch(Exception ex) {
           ex.printStackTrace();
          throw new CreateException(ex.getMessage());
      public void ejbActivate(){}
      public void ejbPassivate(){}
      public void ejbRemove(){}
      public void setSessionContext(SessionContext ctx){ _ctx = ctx; }
      public void createDepartment(int id, String name, String loc)
      throws AppException {
        try {
          // Connect the AM to the datasource we want to use for the duration
          // of this single method call.
          _am.getTransaction().connectToDataSource(null,DATASOURCE,false);
          // Use the "Departments" view object member of this AM
          ViewObject departments = _am.findViewObject("Departments");
          // Create a new row in this view object.
          Row newDept = departments.createRow();
          // Populate the attributes from the parameter arguments.
          newDept.setAttribute("Deptno", new Number(id));
          newDept.setAttribute("Dname", name);
          newDept.setAttribute("Loc", loc);
          // Add the new row to the view object's default rowset
          departments.insertRow(newDept);
          // Post all changes in the AM, but we don't commit them. The EJB
          // container managed transaction handles the commit.
          _am.getTransaction().postChanges();
        catch(JboException ex) {
          // To be good EJB Container-Managed Transaction "citizens" we have
          // to mark the transaction as needing a rollback if there are problems
          _ctx.setRollbackOnly();
          throw new AppException("Error creating dept "+ id +\n"+ex.getMessage());
        finally {
          try {
            // Disconnect the AM from the datasource we're using
            _am.getTransaction().disconnect();
          catch(Exception ex) { /* Ignore */ }
      private void registerContainerManagedTransactionHandlerFactory() {
        SessionImpl session = (SessionImpl)_am.getSession();
        session.setTransactionHandlerFactory(
          new TransactionHandlerFactory() {
            public TransactionHandler createTransactionHandler() {
              return new ContainerManagedTxnHandlerImpl();
            public JTATransactionHandler createJTATransactionHandler() {
              return new ContainerManagedTxnHandlerImpl();

    Hi Steve, It4s me again;
    About the question I made, I tried with a single assembly-descriptor tag and a single container-transaction tag in the deployment descriptor of the session bean and these were the results.
    java.lang.NullPointerException
         void com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(java.lang.Throwable)
         java.lang.Object com.evermind.server.rmi.RMIConnection.invokeMethod(com.evermind.server.rmi.RMIContext, long, long, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         void __Proxy1.modificaEnvoltura(java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String)
         void SamplemdeController.envolturaControlEJBClient.main(java.lang.String[])
    Then I tried with multiple assembly-descriptor tags each with a single container-transaction tag and the results were:
    java.lang.NullPointerException
         void com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(java.lang.Throwable)
         java.lang.Object com.evermind.server.rmi.RMIConnection.invokeMethod(com.evermind.server.rmi.RMIContext, long, long, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         void __Proxy1.modificaEnvoltura(java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String)
         void SamplemdeController.envolturaControlEJBClient.main(java.lang.String[])
    Finally I tried with a single assembly-descriptor and multiple container tags and the results were:
    java.lang.NullPointerException
         void com.evermind.server.rmi.RMIConnection.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(java.lang.Throwable)
         java.lang.Object com.evermind.server.rmi.RMIConnection.invokeMethod(com.evermind.server.rmi.RMIContext, long, long, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         java.lang.Object com.evermind.server.ejb.StatelessSessionRemoteInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
         void __Proxy1.modificaEnvoltura(java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String)
         void SamplemdeController.envolturaControlEJBClient.main(java.lang.String[])
    How can I make my Stateless Session bean work out?

  • Important conceptual question about Application Module, Maximum Pool Size

    Hello everyone,
    We have a critical question about the Application Module default settings (taking the DB connections from a DataSource)
    I know that on the Web it is generally suggested that each request must end with either a commit or rollback when executing PL/SQL blocks "directly" on the DB without the framework BC/ViewObject/Entity service intervention.
    Now, for some reasons, we started to develop our applications with thinking that each Web Session would reference exactly one DB session (opened by any instance taken from the AM pool) for the whole duration of the session, so that the changes made by each Web session to its DB session would never interfere with the changes made by "other" Web Sessions to "other" DB sessions .
    In other words, because of that convincement we often implemented sort of "transactions" that open and close (with either commit or rollback) each DB session not in/after a single HTTP request, but during many HTTP Requests.
    As a concrete example think of this scenario:
    1. the user presses the "Insert" button. An HTTP request is fired. The action listener is executed and ends up with inserting rows in a table via a PL SQL block (not via the ViewObjects API).
    2. no commit or rollback after the above PL/SQL block is done yet.
    3. finally the user presses a "Commit" or "Rollback" button, firing the call to the appropriate AM methos.
    Those three requests consist of what I called "transaction".
    From the documentation it's clear that there is no guarantee that the couple AM istance + DB session is the same during all the requests.
    This means that, during step 2, it's possible that another user might reference the same "pending" AM/DbSession for his needs and "steal" somehow the work done via PL/SQL after step 1. (This happens because sessions taken by the pool are always rolled back by default.)
    Now my question is:
    Suppose we set the "Maximum Pool Size" parameter to very a great number (always inferior to the maximum number of concurrent users):
    Is there any guarantee that all the requests will be isolated in that case?
    I hope the problem is clear.
    Let me know if you want more details.

    Thanks for the answers.
    If I am right, from all your answers about resource avaiability, this means that even supposing the framework is able to always give us the same AM instance back from the AM pool (by following the session-affinity criterias), there is, however, no "connection affinity" with the connections from the DataSource. This means that the "same AM instance" might take the "a new DB connection", if necessary, from the connection pool of the DataSource. If that happens, that could give us the same problems as taking "a new AM instance" (that is, not following session-affinity) from the beginning, since each time an a new connection is taken (either via a new AM instance or via the same AM instance plus a new DB connection), the corresponding DB session is rolle back by default, clearing all the pending transactions we might have performed before with direct PL/SQL calls bypassing the AM services during the life cycle of our application, so that the new HTTP request will have a clean DB session to start to work with.

  • ADF BC: Optimal Application Module Runtime Configuration

    Have implemented an intranet application for 1000 users using the following technologies implemented on Oracle JDeveloper 10.1.3.0.4:
    ADF BC for my Services layer
    JSF for my Controller layer
    JSF and ADF for my View layer
    ADF Model for my Data layer
    The application is entirely designed by .jspx and .jsp pages (for reports), handling 106 application modules, with several entity and view objects and without any step-by-step stateful scenario. At each page, there appears a commit button to commit the end-user transaction, and a rollback button to return to the previous page.
    The application is database-backed from an Oracle Database 10g, deployed on three application servers Oracle 10.1.3.1 on three different hosts on Suse Linux OS, used data-source connection and AM pooling, and load-balanced by one webcacher in front of the 3 servers.
    Under stress test scenario, on a heavy system load in production environment, several ADF State Management errors were recognized that pushed the webacher and application server with the maximum load to automatic restarts due to either demand for JVM increased heap size or errors from the database that the TNS listener complained it could not handle any more connections.
    Thus, we started a safety/reliability tess for all our application module components (disabling "Enable application module pooling"), and a stress test using a third-party stress tool at work, but we're still faced with several questions.
    (a) What is the best strategy for AM configuration, to quit State Management at all since our application doesn't need it, and if so can it be done globally or declaratively and not individually and programmatically?
    (b) Testing on application module runtime configuration, we observed that not to "hang-on" on a connection -default functionality- but to release it at the end of each HTTP request, as each deployment is concentrated on a single data-source connection pool/single user, brought less open JDBC connections on A.S.? Is this the optimal run-time configuration than the default for our case?
    (c) If State Management errors are resolved, and using a software balancer before 3 application servers, regulate the traffice by 1/3 to each, is it possible that a system crash will be avoided next time?
    So, our problems related to ADF tunning and State Management Errors, but we need a good advice on this topic as the overall documentation is case-specific.

    Chapter 29 "Understanding Application Module Pooling" in the ADF Developer's Guide for Forms/4GL Developers on the ADF Learning Center at http://www.oracle.com/technology/products/adf/learnadf.html is the best place to start. There is no "magic" optimal configuration that I (or anyone here, really) can suggest to you. You need to understand the various "knobs and dials" that control the pool sizing and pool cleanup behavior, and then apply application-specific information to this information to derive what the optimal configuration for your particular application will be. The chapter explains how the application module pool and database connection pool interact, and in which situations it is best to change the default setting of the jbo.doconnectionpooling property to true.
    Chapter 28 "Application Module State Management" describes the functionality of that facility of the framework, as well as how to release the application module in stateless, unmanaged mode if you need to.
    By following the tips in the section "28.3.2.4 Setting Release Level in an Custom ADF PageLifecycle" (which builds on information introduced in section "10.5.4.1 Globally Customizing the ADF Page Lifecycle"), you can generically impose a different release level in your application without "touching" every page.
    As a general rule, if you have:
    (*) Lots of distinct application modules
    (*) Each of which is used as a separate data control (rather than being nested inside a containing application module as described in section "8.9.3 Root Application Modules Versus Nested Application Module Usages" of the dev guide)
    (*) Each of which uses the same database connection
    Then as described in section "29.8 How Database and Application Module Pools Cooperate" in the guide, your application can decrease the total overall number of connections used by using the non-default setting of jbo.doconnectionpooling=true.
    Applications using many distinct data controls in the span of a single user's session need to be aware of Bug# 4566186 ("PERF: ADFBINDINGFILTER CHECKS OUT ALL ADF BC DATA CONTROLS USED AT LEAST ONCE"). This issue has been fixed in JDev/ADF 11g, but apparently the fix was too complex to accommodate a 10.1.X backport. I'm trying to document a workaround and publish it on my blog, but I'm not finished with it yet.

  • Nested Application Module and child AM remove

    Hi,
    I have 2 pages. Page A and Page B.
    1. Page A has root am as RootAM and child am as PageAAM1(oracle.apps.xxxx.component1.server.PageAAM).
    2. page B has root am as RootAM and child am as PageBAM1(oracle.apps.xxxx.component2.server.PageBAM).
    Both the pages have the same AM hierarchy. And child regions have both the AM Defination and instance specified.
    Now the question:
    I first come to page A. Do some transactions on this page. Now here i have a button to navigate to Page B. Click on button. Navigate to Page B. Here on Page B do some other tranactions. I have a return button on Page B. When i click on Return button, I release the PageBAM1 usiing the method am.remove(). ANd then formard immediately to PageA.
    At this point of time, I am getting an error soemthing like this:
    oracle.apps.fnd.framework.OAException: oracle.jbo.NoObjException: JBO-25003: Object RootAM.PageBAM1 of type ApplicationModule not found
    Does any one has any idea. What might be the cause and solutiion.
    Thanks,
    Anand

    am.remove() removes the object from the rootApplicationModule, so when you navigate to the page again
    the OAF will try to use the childAM and you will get this error
    because you have already removed it in your previous call.
    It is recommend to use am.remove() only for the Application modules create through programs.
    Your really obsessed with releasing memory occupied by child AM. And you don't have any logical reasons for that.
    Remove the AM only if you want to rollback or commit the transaction.
    otherwise don't remove the child AM at all.
    --Prasanna                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Multiple Application Modules

    I'm currently working on a BC4J/Struts project that requires accessing multiple disparate databases.
    I've setup 2 separate BC4J projects, one is the primary project that the Struts project uses as it's application module (Stateful). The secondary BC4J project is accessing a different database (Stateless).
    I've created methods in the primary application module to access the secondary application module. I'm currently using the Configuration.createRootApplicationModule() method create an instance of the secondary application module within the primary application module.
    Is there anything wrong with this approach?
    How have others achieved this?
    Thank you.

    Hi,
    Configuration.createRootApplicationModule will use the ApplicationPool (caching mechanism). This is intended for programmatic use and is okay to use when accessing a different root AM from within another AM. Please note that this will set up a different transaction context in the second AM that will not be nested within the first (i.e. the framework will not commit the second when commiting the first). If this is not the desired architecture then you should nest the second AM rather than using a programmatic approach.
    You should always release the second AM when done. Best practice recommends that the createRootApplciationModule...releaseRootApplicationModule pair are performed in a try...finally block. If you release with the remove parameter=false -- will release the AM to the pool for reuse.
    Hope this helps,
    JR

  • When the application module starts the trans?

    Hi,
    For ADF application module, when does it start a trans?Is it the case the AM method(even read only method) exposed to view layer, then the trans starts automatically when the page is loaded? Or when getDBTransaction() is called? or even latter when actual update or some specific method is called from the trans? Just wondering whether a commit/rollback is expected when even an exposed method is called by view layer even it is readonly.
    Hui

    Thx, Tim.
    We are use optimistic in the AMs. We have some AMs just do data query. But there is VPD on one of the table, query on the table will trigger the VPD table updates from database, and if db side detects the parent query sql has transaction associated, the vpd related update will not be committed and expects the parent trans will be commit/rollback But if the AM is cached, and no explicit commit/rolback was issued. Will the underlying VPD updates stay there not commit/rollback
    Hui

  • ScheduledExecutorService and Application Module

    I have an Long running job which is submitted from UI, so I used ScheduledExecutorService to execute the task by passing the reference of Application Module. Now the Thread makes some database commits new rows. I have RichPoll which will keep pooling for the progress.
    As Soon as the data is inserted I call transaction commit.
    Now What i noticed is the data committed in the Run method is not available in DB until the run method completes , Any idea what's going wrong
    public class MyClass implements Runnable {
    private MyAMImpl aM;
    public String doAction() {
    FacesContext fc = FacesContext.getCurrentInstance();
    Application app = fc.getApplication();
    ExpressionFactory elFactory = app.getExpressionFactory();
    ELContext elContext = fc.getELContext();
    ValueExpression valueExp =
    elFactory.createValueExpression(elContext, "#{data.MyAMDataControl.dataProvider}",
    Object.class);
    aM = (MyAMImpl )valueExp.getValue(elContext);
    ScheduledExecutorService ses = Executors.newScheduledThreadPool(1);
    setService(ses);
    ses.schedule(this, 3, TimeUnit.SECONDS);
    public void run() {
    try {
    String bug = this.bug;
    am.executeTask();
    } catch (Exception e) {
    e.toString();
    }

    Hi,
    how should we know if the work is done in the part that you don't share? Have you debugged it to ensure the commit happens ?
    Frank

Maybe you are looking for