Why jta transaction

It is best to think of the components involved in distributed transactions as independent processes, rather than in terms of location on a particular computer. Several of the components may reside on one machine, or they may be spread among several machines.

The diagrams in the following examples may show a component on a particular computer, but the relationship among the processes is the primary consideration. The simplest form of relational database access involves only the application, a resource manager, and a resource adapter. The application is simply the end-user access point to send requests to, and obtain data from, a database.

All of the actual database management is handled by this component. The resource adapter is the component that is the communications channel, or request translator, between the "outside world," in this case the application, and the resource manager. For our discussion, this is a JDBC driver. The following description is of a resource manager local transaction , that is, one transaction that is confined to a single, specific enterprise database.

The application sends a request for data to the JDBC driver, which then translates the request and sends it across the network to the database. The database returns the data to the driver, which then translates the result to the application, as illustrated in the following diagram:. This example illustrates the basic flow of information in a simplified system; however, the enterprise of today uses application servers, which adds another component to the process.

The application server is another component of the transaction process that is addressed by the JTA. Application servers handle the bulk of application operations and take some of the load off of the end-user application.

Building on the preceding example, we see that the application server adds another process tier to the transaction:. Up to this point, our examples illustrate a single, local transaction and describe four out of the five components of the distributed transaction model. The fifth component, the transaction manager, comes into consideration only when transactions are to be distributed. As we stated previously, a distributed transaction is a transaction that accesses and updates data on two or more networked resources.

These resources could consist of several different RDBMSs housed on a single sever, for example, Oracle, SQL Server, and Sybase; or they could include several instances of a single type of database residing on a number of different servers. In any case, a distributed transaction involves coordination among the various resource managers. This coordination is the function of the transaction manager. The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction.

Container-managed transaction is available to all EJBs. However, the bean-managed transactions are available for session beans and MDBs. Specify the type of demarcation in the bean deployment descriptor. To configure the bean to use bean-managed transactional demarcation, define this element to be Bean.

Table briefly describes the transaction attribute types that you should specify in the deployment descriptor. Table Transaction Attributes. If the bean invoker calls the bean while involved in a transaction, then the invoker's transaction is suspended, the bean executes, and when the bean returns, the invoker's transaction is resumed.

If the invoker is not involved in a transaction, then the container starts a new transaction for the bean. This attribute is the default. If the invoker has begun a transaction, then the invoker's transaction context is used by the bean. If the invoker calls while involved in a transaction, then the invoker's transaction is suspended until the bean completes.

No bean implementation is necessary to start, commit, or roll back the transaction. The container handles all these functions based on the transaction attribute that is specified in the deployment descriptor. In addition, you must be careful to retrieve the data source connection after you start the transaction, not before.

For programmatic transaction demarcation, the bean developer can use either the JTA user transaction interface or the JDBC connection interface methods. The bean developer must explicitly start and commit or roll back transactions within the timeout interval. Web components JSP, servlets can use programmatic transaction demarcation.

Stateless and stateful session beans can use it; entity beans cannot, and thus must use declarative transaction demarcation. This form of transaction demarcation is not required by the J2EE specification, and is not recommended for performance and latency reasons. OC4J does not support client-side transaction demarcation. The Web component or bean writer must explicitly issue begin, commit, and rollback methods of the UserTransaction interface, as follows:.

The java. Connection class provides commit and rollback methods. JDBC transactions implicitly begin with the first SQL statement that follows the most recent commit, rollback, or connect statement.

The main focus of JTA is to declaratively or programmatically start and end simple and global transactions. When a global transaction is completed, all changes are either committed or rolled back. The difficulty in implementing a two-phase commit transaction is in the configuration details. For two-phase commit, you must use only a nonemulated data source. For more information on nonemulated data sources, refer to "Nonemulated Data Sources". Refer to this example when configuring your JTA two-phase commit environment.

When a global transaction multiple databases, the changes to these resources must all be committed or rolled back at the same time. That is, when the transaction ends, the transaction manager contacts a coordinator—also known as a two-phase commit engine—to either commit or roll back all changes to all included databases. The two-phase commit engine is an Oracle9 i Database Server database that you must configure with the following:. Fully-qualified database links from itself to each of the databases involved in the transaction.

When the transaction ends, the two-phase commit engine communicates with the included databases over their fully qualified database links. A user that is designated to create sessions to each database involved and is given the responsibility of performing the commit or rollback. The user that performs the communication must be created on all involved databases and be given the appropriate privileges.

To facilitate this coordination, perform the following database and OC4J configuration steps shown in the next two subsections. Designate and configure an Oracle9 i Database Server database as the two-phase commit engine with the following steps:. For example, if the user that is needed for completing the transaction is COORDUSR , do the following on the two-phase commit engine and each database involved in the transaction:.

This step is necessary for the two-phase commit engine to communicate with each database at the end of the transaction. Figure shows two databases involved in the transaction. To configure two-phase commit coordination: First, define the database that is to act as the two-phase commit engine, then configure it as follows:.

Define a nonemulated data source, using OrionCMTDataSource , for the two-phase commit engine database in the data-sources. It is the most natural way for a Java EE application to demarcate its transactions.

Moreover, using standard JTA transactions ensures the portability of your application. Use JTA transactions in your applications. They provide more flexibility than local transactions by enabling work in a distributed environment.

Unlike JTA transactions, local transactions work with a single resource manager, which manages the transactions. You can code local transaction demarcation in your application, but you must use local transactions carefully. You may choose to use local transactions in a simple scenario, which does not require sophisticated transaction management. You would use a JTA transaction in basically every other scenario.

There's nothing to setup and they Just Work. In most cases it's advised to use those as they are easier, cleaner and less error prone. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. What is the difference between JTA and a local transaction? Ask Question. Asked 9 years, 8 months ago.

Active 2 days ago. Viewed 44k times.