Degrees of isolation:
degree 0 - a transaction does not overwrite data updated by another user or process ("dirty data") of other transactions
degree 1 - degree 0 plus a transaction does not commit any writes until it completes all its writes (until the end of transaction)
degree 2 - degree 1 plus a transaction does not read dirty data from other transactions
degree 3 - degree 2 plus other transactions do not dirty data read by a transaction before the transaction commits
dimanche 28 octobre 2007
Serializability
An important concept to understanding isolation through transactions is serializability. Transactions are serializable when the effect on the database is the same whether the transactions are executed in serial order or in an interleaved fashion.
Concurrent Transactions
Concurrent transactions are transactions that occur at the same time, such as shared multiple users accessing shared objects.
As an example, if two people are updating the same catalog item, it's not acceptable for one person's changes to be "clobbered" when the second person saves a different set of changes. Both users should be able to work in isolation, working as though he or she is the only user. Each set of changes must be isolated from those of the other users.
As an example, if two people are updating the same catalog item, it's not acceptable for one person's changes to be "clobbered" when the second person saves a different set of changes. Both users should be able to work in isolation, working as though he or she is the only user. Each set of changes must be isolated from those of the other users.
Isolation and ACID properties
The isolation portion of the ACID properties is needed when there are concurrent transactions. The safeguards used by a DBMS to prevent conflicts between concurrent transactions are a concept referred to as isolation.
samedi 27 octobre 2007
Java Transaction Design Strategies
Understanding how transaction management works in Java and developing an effective transaction design strategy can help to avoid data integrity problems in your applications and databases and ease the pain of inevitable system failures.
This book is about how to design an effective transaction management strategy using the transaction models provided by Java-based frameworks such as EJB and Spring. Techniques, best practices, and pitfalls with each transaction model will be described. In addition, transaction design patterns will bring all these concepts and techniques together and describe how to use these models to effectively manage transactions within your EJB or Spring-based Java applications.
UserTransaction Interface
The UserTransaction interface defines the methods that allow an application to explicitly manage transaction boundaries.
TransactionManager Interface
The TransactionManager interface defines the methods that allow an application server to manage transaction boundaries.
Oracle SQL Transaction Management
There is no Oracle SQL statement to explicitly start a new transaction. Oracle server implicitly starts a new transaction with the following two conditions:
* The first executable statement of a new user session will automatically start a new transaction.
* The first executable statement after a previous transaction has been ended will automatically start a new transaction.
There are several ways a current Oracle transaction can be ended:
* Running the COMMIT statement will explicitly end the current transaction.
* Running the ROLLBACK statement will explicitly end the current transaction.
* Running any DDL statement will implicitly end the current transaction.
* Disconnecting a user session will implicitly end the current transaction.
* Killing a user session will implicitly end the current transaction.
* The first executable statement of a new user session will automatically start a new transaction.
* The first executable statement after a previous transaction has been ended will automatically start a new transaction.
There are several ways a current Oracle transaction can be ended:
* Running the COMMIT statement will explicitly end the current transaction.
* Running the ROLLBACK statement will explicitly end the current transaction.
* Running any DDL statement will implicitly end the current transaction.
* Disconnecting a user session will implicitly end the current transaction.
* Killing a user session will implicitly end the current transaction.
XAResource interface
This interface is a Java mapping of the industry standard X/Open XA protocol that allows a resource manager to participate in a transaction. The component of the driver connected with the XAResource interface is responsible for "translating" between the transaction manager and the resource manager.
JTA Interfaces
Developers of transaction manager code must be conversant with all three interfaces of JTA: UserTransaction, TransactionManager, and XAResource, which are described in the Sun Java Transaction API (JTA) specification. The JDBC API Tutorial and Reference, Third Edition is also a useful reference.
Two-Phase Commit Protocol
The transaction manager controls the boundaries of the transaction and is responsible for the final decision as to whether or not the total transaction should commit or rollback. This decision is made in two phases, called the Two-Phase Commit Protocol.
In the first phase, the transaction manager polls all of the resource managers (RDBMSs) involved in the distributed transaction to see if each one is ready to commit. If a resource manager cannot commit, it responds negatively and rolls back its particular part of the transaction so that data is not altered.
In the second phase, the transaction manager determines if any of the resource managers have responded negatively, and, if so, rolls back the whole transaction. If there are no negative responses, the translation manager commits the whole transaction, and returns the results to the application.
In the first phase, the transaction manager polls all of the resource managers (RDBMSs) involved in the distributed transaction to see if each one is ready to commit. If a resource manager cannot commit, it responds negatively and rolls back its particular part of the transaction so that data is not altered.
In the second phase, the transaction manager determines if any of the resource managers have responded negatively, and, if so, rolls back the whole transaction. If there are no negative responses, the translation manager commits the whole transaction, and returns the results to the application.
Transaction Branch
Although the final commit/rollback decision treats the transaction as a single logical unit, there can be many transaction branches involved. A transaction branch is associated with a request to each resource manager involved in the distributed transaction.
Requests to three different RDBMSs, therefore, require three transaction branches. Each transaction branch must be committed or rolled back by the local resource manager.
Requests to three different RDBMSs, therefore, require three transaction branches. Each transaction branch must be committed or rolled back by the local resource manager.
XA Specification
Industry standard XA interface based on the X/Open CAE Specification Distributed Transaction Processing: The XA Specification.
Transaction Manager
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. A commit decision should lead to a successful transaction; rollback leaves the data in the database unaltered. 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.
Most enterprises use transaction managers and application servers because they manage distributed transactions much more efficiently than an application can.
The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. A commit decision should lead to a successful transaction; rollback leaves the data in the database unaltered. 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.
Most enterprises use transaction managers and application servers because they manage distributed transactions much more efficiently than an application can.
The Application Server
Application servers handle the bulk of application operations and take some of the load off of the end-user application. Application server adds another process tier to the transaction.
The first step of the distributed transaction process is for the application to send a request for the transaction to the transaction manager.
The first step of the distributed transaction process is for the application to send a request for the transaction to the transaction manager.
The Resource Adapter
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. In Java Context, this is a JDBC driver.
The Resource Manager
The resource manager is generally a relational database management system (RDBMS), such as Oracle or SQL Server. All of the actual database management is handled by this component.
Distributed Transaction Processing Model
The distributed transaction processing (DTP) model defines several components:
* The application
* The application server
* The transaction manager
* The resource adapter
* The resource manager
* The application
* The application server
* The transaction manager
* The resource adapter
* The resource manager
Distributed Transaction
A transaction defines a logical unit of work that either completely succeeds or produces no result at all. 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.
JTA
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.
The JTA specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transactions system: the application, the application server, and the resource manager that controls access to the shared resources affected by the transactions.
The JTA specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transactions system: the application, the application server, and the resource manager that controls access to the shared resources affected by the transactions.
Inscription à :
Articles (Atom)