Application Module:
The interface for Application Modules. An Application Module is a logical container for coordinated objects related to a particular task with optional programming logic.
Root Application Module and Nested Application Module:
An Application Module may be a root Application Module or a nested Application Module.
A root Application Module is not contained in another Application Module. It provides transaction context for all objects contained in it. It may optionally contain nested Application Modules. A root Application Module is created through JDNI calls.
A nested Application Module is contained in another Application Module. The containing Application Module is referred to as the parent Application Module. If one traverses this containership ancestry, one will eventually find the root Application Module (which does not have a parent Application Module). A nested Application Module uses the transaction context provided by the root Application Module. Thus, data modifications performed in Application Modules parented by one root Application Module will commit or rollback together.
Transaction:
Associated with the root Application Module is the Transaction object, which provides this transaction context. From any (root or nested) Application Module, the user can retrieve the transaction object through a call to getTransaction(). In reality, getTransaction() first locates the root Application Module and then returns the transaction object from it.
The Transaction object manages connection to database and Entity caches. Thus, changes made through one View Object are visible to other View Objects as long as these View Objects all parented by the one root Application Module. In contrast, if two View Objects are parented by two separate root Application Modules, then changes made through the View Object will not be seen by the second View Object until the changes are committed to database through the first root Application Module and the second VO executes query (to retrieve the most up-to-date data from database).
Creating Application Module
A root Application Module is created by:
Finding the Application Module home through JNDI.
Calling create() on the Application Module home.
Here is a sample code to create a root Application Module:
java.util.Hashtable env = new java.util.Hashtable();
// Add environment entries into env...
javax.naming.Context ic = new InitialContext(env);
// 'defName' is the JNDI name for the Application Module
// definition from which the root Application Module is to
// be created
String defName = ...;
oracle.jbo.ApplicationModuleHome home = ic.lookup(defName);
oracle.jbo.ApplicationModule am = home.create();
One creates a nested Application Module by calling createApplicationModule on the parent Application Module.
Application Module definitions are managed by oracle.jbo.server.MetaObjectManager. One can find a specific definition object by issuing:
String defName = ...;
oracle.jbo.server.ApplicationModuleDefImpl def;
def = oracle.jbo.server.ApplicationModuleDefImpl.findDefObject(defName);
http://myexpwithoracleadf.blogspot.in/2013/04/oracle-adf-manage-transaction-using.html
The interface for Application Modules. An Application Module is a logical container for coordinated objects related to a particular task with optional programming logic.
Root Application Module and Nested Application Module:
An Application Module may be a root Application Module or a nested Application Module.
A root Application Module is not contained in another Application Module. It provides transaction context for all objects contained in it. It may optionally contain nested Application Modules. A root Application Module is created through JDNI calls.
A nested Application Module is contained in another Application Module. The containing Application Module is referred to as the parent Application Module. If one traverses this containership ancestry, one will eventually find the root Application Module (which does not have a parent Application Module). A nested Application Module uses the transaction context provided by the root Application Module. Thus, data modifications performed in Application Modules parented by one root Application Module will commit or rollback together.
Transaction:
Associated with the root Application Module is the Transaction object, which provides this transaction context. From any (root or nested) Application Module, the user can retrieve the transaction object through a call to getTransaction(). In reality, getTransaction() first locates the root Application Module and then returns the transaction object from it.
The Transaction object manages connection to database and Entity caches. Thus, changes made through one View Object are visible to other View Objects as long as these View Objects all parented by the one root Application Module. In contrast, if two View Objects are parented by two separate root Application Modules, then changes made through the View Object will not be seen by the second View Object until the changes are committed to database through the first root Application Module and the second VO executes query (to retrieve the most up-to-date data from database).
Creating Application Module
A root Application Module is created by:
Finding the Application Module home through JNDI.
Calling create() on the Application Module home.
Here is a sample code to create a root Application Module:
java.util.Hashtable env = new java.util.Hashtable();
// Add environment entries into env...
javax.naming.Context ic = new InitialContext(env);
// 'defName' is the JNDI name for the Application Module
// definition from which the root Application Module is to
// be created
String defName = ...;
oracle.jbo.ApplicationModuleHome home = ic.lookup(defName);
oracle.jbo.ApplicationModule am = home.create();
One creates a nested Application Module by calling createApplicationModule on the parent Application Module.
Application Module definitions are managed by oracle.jbo.server.MetaObjectManager. One can find a specific definition object by issuing:
String defName = ...;
oracle.jbo.server.ApplicationModuleDefImpl def;
def = oracle.jbo.server.ApplicationModuleDefImpl.findDefObject(defName);
Manage Transaction using Application Modules
Client applications connect to databases and manage transactions by using the oracle.jbo.Transaction interface. Some useful methods of the Transaction interface with regard to Application Modules are:- commit - Commit the transaction; saves all changes to the database. If the database connection is established, the transaction is implicitly started.
- connect - Attempt to establish a connection to the given database URL.
- disconnect - Disconnect the server from the database.
- getLockingMode - Get the preferred locking mode for this transaction. Currently the locking mode defaults to LOCK_PESSIMISTIC.
- rollback - Rollback the transaction; discard all changes.
- setLockingMode - Set the preferred locking mode for this transaction. Changing the locking mode affects only subsequent locks that are placed.
// Assume that appMod has been declared and initialized elsewhere.
try {
if (updateAttr(vo, newAttrVal)) {
// Commit changes to the database, making
// updated data available to other Application Modules.
appMod.getTransaction().commit();
System.out.println("\n Transaction committed. \n");
}
else {
appMod.getTransaction().rollback();
System.out.println("\n Transaction rolled back. \n");
}
} catch (Exception e) {
e.printStackTrace();
}
Entity Objects are not directly exposed to the client tier. Instead, clients access an Entity Object's data through a View Object in an Application Module. All View Objects within the transaction share the same Entity Object caches. View Objects and Entity Objects communicate via events and/or Java calls (not by using remote interface proxies).
A View Object, expressed as a query on top of underlying Entity Objects, shapes the result set for presentation. Because data is cached at the Entity Object level and all View Object references within the same transaction share the Entity Objects, changes made through one View Object are immediately available through other View Objects in the same transaction. The following code example shows the interaction between Application Modules, View Objects, and the database as values are changed, posted, and committed.
package amdemo;
import oracle.jbo.*;
import java.util.Hashtable;
import javax.naming.*;
public class TestAm {
public static void main(String[] args) {
final String amName1 = "am1.AppMod1";
final String amName2 = "am2.AppMod2";
final String voName1 = "am1.DeptView1";
final String voName2 = "am1.DeptView2";
final String voName3 = "am2.DeptView3";
final String voName4 = "am2.DeptView4";
final String connStr = "jdbc:oracle:thin:scott/tiger@jtora815:1521:ORCL";
// Set environment for local deployment.
Hashtable env = new Hashtable(2);
env.put(Context.INITIAL_CONTEXT_FACTORY, JboContext.JBO_CONTEXT_FACTORY);
env.put(JboContext.DEPLOY_PLATFORM, JboContext.PLATFORM_LOCAL);
ApplicationModule appMod1 = null;
ApplicationModule appMod2 = null;
try {
javax.naming.Context ic = new InitialContext(env);
ApplicationModuleHome home1 =
(ApplicationModuleHome)ic.lookup(amName1);
appMod1 = home1.create();
appMod1.getTransaction().connect(connStr);
ApplicationModuleHome home2 =
(ApplicationModuleHome)ic.lookup(amName2);
appMod2 = home2.create();
appMod2.getTransaction().connect(connStr);
} catch(Exception e){
e.printStackTrace();
}
ViewObject vo1 = appMod1.createViewObject("vo1", voName1);
ViewObject vo2 = appMod1.createViewObject("vo2", voName2);
ViewObject vo3 = appMod2.createViewObject("vo3", voName3);
//ViewObject vo4 = appMod2.createViewObject("vo4", voName4);
Row r1 = vo1.first();
r1.setAttribute("Loc", "asdf");
System.out.println("vo1 before AppMod1 post " + r1.getAttribute("Loc"));
Row r2 = vo2.first();
System.out.println("vo2 before AppMod1 post " + r2.getAttribute("Loc"));
vo3.executeQuery();
Row r3 = vo3.first();
System.out.println("vo3 before AppMod1 post " + r3.getAttribute("Loc"));
//Row r4 = vo4.first();
//System.out.println("vo4 before AppMod1 post " + r4.getAttribute("Loc"));
appMod1.getTransaction().postChanges();
System.out.println("vo1 after AppMod1 post " + r1.getAttribute("Loc"));
r2 = vo2.first();
System.out.println("vo2 after AppMod1 post " + r2.getAttribute("Loc"));
r3 = vo3.first();
System.out.println("vo3 after AppMod1 post " + r3.getAttribute("Loc"));
//r4 = vo4.first();
//System.out.println("vo4 after AppMod1 post " + r4.getAttribute("Loc"));
try {
appMod1.getTransaction().commit();
System.out.println("Commit succeeded.");
} catch (oracle.jbo.JboException e) {
System.out.println("Commit failed. " + e);
}
System.out.println("vo1 after AppMod1 commit " + r1.getAttribute("Loc"));
r2 = vo2.first();
System.out.println("vo2 after AppMod1 commit " + r2.getAttribute("Loc"));
vo3.executeQuery();
r3 = vo3.first();
System.out.println("vo3 after AppMod1 commit " + r3.getAttribute("Loc"));
//r4 = vo4.first();
//System.out.println("vo4 after AppMod1 commit " + r4.getAttribute("Loc"));
// Keep the console window open so you can see what happened.
System.out.println("\n Press Enter to close this window.");
try { System.in.read(); } catch (Exception e) {}
}
}
http://myexpwithoracleadf.blogspot.in/2013/04/oracle-adf-application-module-basics.html?view=sidebar
http://myexpwithoracleadf.blogspot.in/2013/04/oracle-adf-manage-transaction-using.html
