ATG - how to use the Transaction Manager

Basic concepts of Java transaction

In its simplest definition, a transaction is a set of actions that is treated as an atomic unit; either all actions take place (the transaction commits), or none of them take place (the transaction rolls back).

Managing transactions is one of the primary tasks of an application server. The application server keeps track of transactions, remembering which transaction is associated with which request, and what transactional resources (such as JDBC or JMS connection) are involved. Each active transaction is represented by a transaction object, which implements the interface javax.transaction.Transaction.

A transaction is usually associated with a thread and only one transaction can be associated with a thread at any one time. A central service, called the Transaction Manager, is responsible for keeping track of all these transactions. The Transaction Manager is implemented through the Java Transaction API (JTA).

Transaction and Dynamo applications

In Dynamo applications, the TransactionManager object is represented by a Nucleus component, /atg/dynamo/transaction/TransactionManager. Nucleus components can get a pointer directly to the /atg/dynamo/transaction/TransactionManager component. Dynamo also exposes this component to standard J2EE components, such as servlets and EJBs, through the JNDI name dynamo:/atg/dynamo/transaction/TransactionManager.

In order for a transaction to keep track of all the resources, those resources must be enlisted with the transaction. Application server does this when we get the resource connection through a conection factory. These factory objects are available in Dynamo as Nucleus services. For example, the standard Dynamo DataSource object is found at /atg/dynamo/service/jdbc/JTDataSource. Nucleus components should acquire resources through these proper connection factory services, rather than accessing drivers directly from their managers. Dynamo’s default configuration uses a JDBC driver configured to simulate two-phase commits to work with JDBC drivers that do not support the two-phase commit protocol.

Best practice in dynamo transaction handling

The application should not attempt to acquire the resource once and pass it around from component to component in the interest of avoiding the code for acquiring or closing the connection. The application server make sure that same Connection object must be returned each time a connection is requested throughout a single transaction. Application components are required to close JDBC connections when they finish doing their individual portion of work. Rather than actually closing the connection to the database, the application server intercepts these close requests and interprets them as signals from the application that it is done with the connection for the time being. The application server then responds to that signal by returning the connection to a pool, or by maintaining the connection’s transactional association.

Transaction demarcation : doing small and complete tasks

For doing some small set of tasks by a thread which is already in a transaction, the thread can suspend the current transaction. After suspending, the transaction still exists and keeps track of the resources it has used so far, but any further work done by the thread does not use that transaction. After the transaction is suspended, the thread can create a transaction. After ending this new transaction, the previously suspended transaction can be resumed. An application server can suspend and resume transactions through calls to the TransactionManager object , but individual applications should not perform these operations directly. Instead, applications should use J2EE transaction demarcation facilities.

Transaction demarcation always wraps a sequence of actions. The demarcation initializes some transactional behavior before the demarcated area begins, then ends that transactional behavior when the demarcated area ends. The application server uses these demarcations to determine the appropriate calls to the TransactionManager object.

following are the differetn transaction demarcation modes ---> Required, RequiresNew , NotSupported , Supports , Mandatory , Never.

The class atg.dtm.UserTransactionDemarcation can be used by J2EE components and Nucleus components to perform basic transaction demarcation. This class accesses the UserTransaction object to perform its operations. The class atg.dtm.TransactionDemarcation can be used by Nucleus components to demarcate areas of code at a fine granularity. J2EE components cannot use this class, because it accesses the TransactionManager object directly.

Demarcation Code Sample


try{
try{
atg.dtm.TransactionDemarcation transactionDemarcation = new TransactionDemarcation();
.....
if (isTransactionMarkedAsRollBack()){
    getTransactionManager().getTransaction().rollback();
}
transactionDemarcation.begin(getTransactionManager(),transactionDemarcation.REQUIRES_NEW);
.....
}finally {
transactionDemarcation.end();
}
}catch (TransactionDemarcationException transactionDemarcationException) {
    <handle the transactionDemarcationException>
}

Demarcation in Pages

The DSP tag libraries dsp:beginTransaction, dsp:commitTransaction, dsp:demarcateTransaction, dsp:rollbackTransaction, dsp:setTransactionRollbackOnly, dsp:transactionStatus are available for transaction management. Also the droplets /atg/dynamo/transaction/droplet/Transaction and /atg/dynamo/transaction/droplet/EndTransaction  can be used to start and transaction in pages.

Debugging rollbacks


To debug the transaction rollbacks, in the TranasactionManager component, set debugTracesForRollbacks to true. So that application throws the rollback details, else you will never know which component actually set transaction to rollback.