![]() |
![]() |
|
This section discusses the following topics:
This topic includes the following sections:
One of the most fundamental features of the WebLogic Server system is transaction management. Transactions are a means to guarantee that database transactions are completed accurately and that they take on all the ACID properties of a high-performance transaction, including:
WebLogic Server protects the integrity of your transactions by providing a complete infrastructure for ensuring that database updates are done accurately, even across a variety of resource managers. If any one of the operations fails, the entire set of operations is rolled back.
WebLogic Server supports transactions in the Sun Microsystems, Inc., Java 2, Enterprise Edition (J2EE) programming model. WebLogic Server provides full support for transactions in Java applications that use Enterprise JavaBeans, in compliance with the Enterprise JavaBeans Specification 2.0, published by Sun Microsystems, Inc. WebLogic Server also supports the Java Transaction API (JTA) Specification 1.0.1, also published by Sun Microsystems, Inc.
WebLogic Server supports the Sun Microsystems, Inc. Java Transaction API (JTA), which is used by:
For information about JTA, see the following sources:
Distributed Transactions and the Two-Phase Commit Protocol
WebLogic Server supports distributed transactions and the two-phase commit protocol for enterprise applications. A distributed transaction is a transaction that updates multiple resource managers (such as databases) in a coordinated manner. In contrast, a local transaction updates a single resource manager. The two-phase commit protocol is a method of coordinating a single transaction across two or more resource managers. It guarantees data integrity by ensuring that transactional updates are committed in all of the participating databases, or are fully rolled back out of all the databases, reverting to the state prior to the start of the transaction. In other words, either all the participating databases are updated, or none of them are updated.
Distributed transactions involve the following participants:
The first phase of the two-phase commit protocol is called the prepare phase. The required updates are recorded in a transaction log file, and the resource must indicate, through a resource manager, that it is ready to make the changes. Resources can either vote to commit the updates or to roll back to the previous state. What happens in the second phase depends on how the resources vote. If all resources vote to commit, all the resources participating in the transaction are updated. If one or more of the resources vote to roll back, then all the resources participating in the transaction are rolled back to their previous state.
Support for Business Transactions
WebLogic JTA provides the following support for your business transactions:
Transactions are appropriate in the situations described in the following list. Each situation describes a transaction model supported by the WebLogic Server system. Keep in mind that distributed transactions should not span more than a single user input screen; more complex, higher level transactions are best implemented with a series of distributed transactions.
For example, consider a travel agent application. The client application needs to arrange for a journey to a distant location; for example, from Strasbourg, France, to Alice Springs, Australia. Such a journey would inevitably require multiple individual flight reservations. The client application works by reserving each individual segment of the journey in sequential order; for example, Strasbourg to Paris, Paris to New York, New York to Los Angeles. However, if any individual flight reservation cannot be made, the client application needs a way to cancel all the flight reservations made up to that point.
For example, consider an Internet-based online shopping cart application. Users of the client application browse through an online catalog and make multiple purchase selections. When the users are done choosing all the items they want to buy, they proceed to check out and enter their credit card information to make the purchase. If the credit card check fails, the shopping application needs a way to cancel all the pending purchase selections in the shopping cart, or roll back any purchase transactions made during the conversation.
For example, consider a banking application. The client invokes the transfer operation on a teller object. The transfer operation requires the teller object to make the following invocations on the bank database:
If the credit invocation on the bank database fails, the banking application needs a way to roll back the previous debit invocation.
This topic includes the following sections:
Figure 1-1 illustrates how transactions work in a WebLogic Server EJB application.
Figure 1-1 How Transactions Work in a WebLogic Server EJB Application
WebLogic Server supports two types of transactions in WebLogic Server EJB applications:
The sequence of transaction events differs between container-managed and bean-managed transactions.
Container-managed Transactions
For EJB applications with container-managed transactions, a basic transaction works in the following way:
Note: Calling the EJBContext.setRollbackOnly method is allowed only for methods that have a meaningful transaction context.
You can control transaction timeouts by setting the trans-timeout-seconds element using the Administration Console.
For EJB applications with bean-managed transaction demarcations, a basic transaction works in the following way:
Transactions in WebLogic Server RMI Applications
Figure 1-2 illustrates how transactions work in a WebLogic Server RMI application.
Figure 1-2 How Transactions Work in a WebLogic Server RMI Application
For RMI client and server applications, a basic transaction works in the following way:
Obtaining the object reference begins a conversational state between the application and that object. The conversational state continues until the transaction is completed (committed or rolled back). Once instantiated, RMI objects remain active in memory until they are released (typically during server shutdown). For the duration of the transaction, the WebLogic Server infrastructure does not perform any deactivation or activation.
This topic includes the following sections:
This topic provides a walkthrough of sample code fragments from a class in an EJB application. This topic includes the following sections:
The code fragments demonstrate using the UserTransaction object for bean-managed transaction demarcation. The deployment descriptor for this bean specifies the transaction type (transaction-type element) for transaction demarcation (Bean).
Note: These code fragments do not derive from any of the sample applications that ship with WebLogic Server. They merely illustrate the use of the UserTransaction object within an EJB application.
Listing 1-1 shows importing the necessary packages for transactions, including:
Listing 1-1 Importing Packages
import javax.naming.*;
import javax.transaction.UserTransaction;
import javax.transaction.SystemException;
import javax.transaction.HeuristicMixedException
import javax.transaction.HeuristicRollbackException
import javax.transaction.NotSupportedException
import javax.transaction.RollbackException
import javax.transaction.IllegalStateException
import javax.transaction.SecurityException
import java.sql.*;
import java.util.*;
import weblogic.jndi.*;
After importing these classes, initialize an instance of the UserTransaction object to null.
Using JNDI to Return an Object Reference
Listing 1-2 shows using JNDI to look up an object reference.
Listing 1-2 Performing a JNDI Lookup
Context ctx = null;
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
// Parameters for the WebLogic Server.
// Substitute the corect hostname, port number
// user name, and password for your environment:
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "Fred");
env.put(Context.SECURITY_CREDENTIALS, "secret");
ctx = new InitialContext(env);
UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
Listing 1-3 shows starting a transaction by getting a UserTransaction object and calling the javax.transaction.UserTransaction.begin() method. Database operations that occur after this method invocation and prior to completing the transaction exist within the scope of this transaction.
Listing 1-3 Starting a Transaction
UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
tx.begin();
Listing 1-4 shows completing the transaction depending on whether an exception was thrown during any of the database operations that were attempted within the scope of this transaction:
Listing 1-4 Completing a Transaction
tx.commit();
// or:
tx.rollback();
This topic provides a walkthrough of sample code fragments from a class in an RMI application. This topic includes the following sections:
The code fragments demonstrate using the UserTransaction object for RMI transactions. For guidelines on using transactions in RMI applications, see Transactions in RMI Applications.
Note: These code fragments do not derive from any of the sample applications that ship with WebLogic Server. They merely illustrate the use of the UserTransaction object within an RMI application.
Listing 1-5 shows importing the necessary packages, including the following packages used to handle transactions:
Listing 1-5 Importing Packages
import javax.naming.*;
import java.rmi.*;
import javax.transaction.UserTransaction;
import javax.transaction.SystemException;
import javax.transaction.HeuristicMixedException
import javax.transaction.HeuristicRollbackException
import javax.transaction.NotSupportedException
import javax.transaction.RollbackException
import javax.transaction.IllegalStateException
import javax.transaction.SecurityException
import java.sql.*;
import java.util.*;
import weblogic.jndi.*;
After importing these classes, initialize an instance of the UserTransaction object to null.
Using JNDI to Return an Object Reference to the UserTransaction Object
Listing 1-6 shows searching the JNDI tree to return an object reference to the UserTransaction object for the appropriate WebLogic Server domain.
Note: Obtaining the object reference begins a conversational state between the application and that object. The conversational state continues until the transaction is completed (committed or rolled back). Once instantiated, RMI objects remain active in memory until they are released (typically during server shutdown). For the duration of the transaction, the WebLogic Server infrastructure does not perform any deactivation or activation.
Listing 1-6 Performing a JNDI Lookup
Context ctx = null;
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
// Parameters for the WebLogic Server.
// Substitute the corect hostname, port number
// user name, and password for your environment:
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "Fred");
env.put(Context.SECURITY_CREDENTIALS, "secret");
ctx = new InitialContext(env);
UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
Listing 1-7 shows starting a transaction by calling the javax.transaction.UserTransaction.begin() method. Database operations that occur after this method invocation and prior to completing the transaction exist within the scope of this transaction.
Listing 1-7 Starting a Transaction
UserTransaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
tx.begin();
Listing 1-8 shows completing the transaction depending on whether an exception was thrown during any of the database operations that were attempted within the scope of this transaction:
Listing 1-8 Completing a Transaction
tx.commit();
// or:
tx.rollback();
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|