This relationship is illustrated in the following diagram: JTA specifies standard Java interfaces between the transaction manager and the other components in a distributed transaction: the application, the application server, and the resource managers. ![]() A commit decision should lead to a successful transaction rollback leaves the data in the database unaltered. The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. ![]() This coordination is the function of the transaction manager. In any case, a distributed transaction involves coordination among the various resource managers. 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. The database returns the data to the driver, which then translates the result to the application, as illustrated in the following diagram:Īs we stated previously, a distributed transaction is a transaction that accesses and updates data on two or more networked resources. 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 following description is of a resource manager local transaction, that is, one transaction that is confined to a single, specific enterprise database. For our discussion, this is a JDBC driver. 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. All of the actual database management is handled by this component. The resource manager in our discussion is a relational database management system (RDBMS), such as Oracle or SQL Server. The application is simply the end-user access point to send requests to, and obtain data from, a database. The simplest form of relational database access involves only the application, a resource manager, and a resource adapter. The Simplest Case: Application to Database Local Transactions The diagrams in the following examples may show a component on a particular computer, but the relationship among the processes is the primary consideration. Several of the components may reside on one machine, or they may be spread among several machines. 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. In the following sections, we describe these components and their relationship to JTA and database access. ![]() The components involved in the distributed transaction processing (DTP) model that are relevant to our discussion are: In this document, we are concerned primarily with transactions that involve relational database systems. A distributed transaction is simply a transaction that accesses and updates data on two or more networked resources, and therefore must be coordinated among those resources. This document provides an overview of that process and how the DataDirect Connect® for JDBC™drivers relate to it.Ī transaction defines a logical unit of work that either completely succeeds or produces no result at all. The JTA specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the application, the application server, and the resource manager that controls access to the shared resources affected by the transactions. The Java™ Transaction API (JTA) allows applications to perform distributed transactions, that is, transactions that access and update data on two or more networked computer resources.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |