Author: Debu Panda
This example application demonstrates Oracle's support for the transaction context propagation between OC4J instances using ORMI.
Transaction context propagation is necessary if multiple OC4J instances are to participate in a single distributed transaction. A transaction context defines the scope of a transaction and associates all participating resources and transactional operations. All participating threads share the same transaction context.
Multiple OC4J instances need to participate in the same transaction if an OC4J instance makes a remote call into another OC4J instance in the scope of an existing transaction, assuming the EJB semantics for the method support scoping work in a client’s transaction. An example of this is a servlet in OC4J instance 1 obtaining a reference to an EJB residing in OC4J instance 2, starting a transaction and making a method call on the remote EJB in the scope of the transaction. When multiple OC4J instances participate in a single transaction, all work done by the participating OC4J instances as part of the global transaction is guaranteed to be atomic.
There are no special settings required in the container to propagate transaction context between OC4J instances. However, you must configure the Transaction Manager logging to ensure recovery of failed/in-doubt transactions. You have to invoke a remote EJB in a transactional context using RMIInitialContextFactory as in the following code:
env.put(Context.INITIAL_CONTEXT_FACTORY, "oracle.j2ee.rmi.RMIInitialContextFactory"); env.put(Context.PROVIDER_URL, "ormi://localhost:23792/TxProp"); env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin"); env.put(Context.SECURITY_CREDENTIALS, "welcome");
For further information on OC4J, see the following documents on OTN:
This demonstration requires that the following software components are installed and configured correctly:
configuration files are located in the %HOWTO_HOME%/etc directory, including deployment descriptor files such as application.xml.
To run the sample application on an instance of Oracle Application Server 10g 10.1.3 , follow these steps:
Ensure the following environment variables are defined:
Create the table using the table.sql script in the %HOWTO_HOME%/scripts directory.
This example requires a DataSource to be configured to connect to the database that contains the DESTINATION table.
For OC4J, you must configure a datasource in the %ORACLE_HOME%/j2ee/home/config/data-sources.xml file and point it at the schema that owns the DESTINATION table.
An example configuration:
Start OC4J stand alone using the following command after you make the above changes.
If you are using an OracleAS managed install, start using the following command after you make the above changes.
> %ORACLE_HOME%/opmn/bin/opmnctl startall
Ant 1.6.2 is shipped with OC4J and you have to set your PATH environment variable to $ORACLE_HOME/ant/bin. On some operating systems, Ant does not currently support the use of environment variables. If this is the case for your operating system, please modify the ant-oracle.xml file located in the %HOWTO_HOME% directory.
Edit ant-oracle.properties (in the demo
directory) and ensure the following properties are set to the correct values, as indicated below for both OC4J instances :
If you are using OracleAS managed install then you have appropriately change the following properties beside changing oc4j.admin.user and oc4j.admin.password for your managed OC4J instance in OracleAS install.
You have to uncomment appropriate deployer.uri in the ant-oracle.properties based on your environment i.e. a single instance OC4J or a clustered OC4J instance/group managed by OPMN.
You have to make appropriate changes in the
createContext method of
TXPropagationBean.java while per your environment. You have to use
opmn:ormi lookup when looking up an EJB in an OracleAS environment where OC4J instance is managed by OPMN and ORMI port is dynamically allocated.
Run the sample by providing invoking the following URL from your favorite browser:
In this page, enter appropriate data, select appropriate button for transaction option and then click on Execute Demo.
If a transaction does exist, the method will execute using the existing transactional context. When the JSP calls a method on an EJB in process 1, a transaction is started. The EJB in process 1 then calls an EJB in process 2, which causes the transaction to be propagated to process 2. The EJB in process 2 executes using the propagated transaction context. A database insert is done by the bean on process 2 and then by the bean on process 1 when the call to the bean in process 2 returns.
Three different scenarios are executed.
In this document, you should have learned :