Default Transactional Behavior in WebLogic Workshop

Each time a method or callback in your web service is called, WebLogic Workshop begins an implicit transaction that is associated with that method or callback. If the method or callback returns successfully, without throwing an exception, the transaction is committed. If the method or callback fails, the transaction is rolled back, and none of the changes that have happened within the transactional context are committed.

Included within the transactional context are changes to the state of an ongoing conversation, and calls to methods of the Database, Timer, EJB, and JMS controls. If a method fails at any point, operations performed by the method, changes to the conversation state, and operations performed by any of these controls will be rolled back to their original state. For example, if the web service method calls a method on a Database control to create a table, and the web service method fails subsequently on a different call, the database operation will be rolled back.

Any operations performed by a Service control or an Application View control are not included in the transactional context of the web service method or callback. If the web service method fails following a successful call to a method or callback on a Service control, the operation performed by the Service control will not be rolled back.

There is one case in which a Service control is included in the web service’s transactional context to a limited extent. If a method on a Service control has a message buffer, then the queue on that method is included in the transactional context of the web service method. That is, if a failure occurs after a call to a buffered method on a Service control, the method will never be called.

If an exception occurs in a web service method that participates in a conversation, the transaction is rolled back as expected, and the effect on the conversation state depends on whether the the exception is handled. If the exception is handled, the conversation state is updated; if not, the conversation state is not updated. Specifically, if an unhandled exception occurs in a method that starts a conversation, the conversation is never started; if an unhandled exception occurs in a method that continues or finishes a conversation, the conversation state is not updated.

To ensure that conversation state is updated whether or not the method succeeds, handle the exception without rethrowing it, as shown in the following example:

    /**
     * @operation
     * @conversation finish
     */
    public void finish()
    {
    try
        {
        bank.cancelAnalysis()
        }
    catch (ProxyException pe)
        {
        // Log the error, but don't rethrow.
        }
    }

Whether a particular control used by your web service actually participates in the service’s transaction depends on how the resource exposed by the control is configured. For example, a database exposed by a Database control must be configured to use a transactional connection pool in order to participate in the web service’s transaction. Enterprise JavaBeans can support an existing transaction or be configured to create their own transaction rather than to participate in the web service’s transaction. When you’re building your service, you should take into account how the resources that you’re using are configured to participate in distributed transactions.

By default, the implicit transaction initiated by a web service times out after five minutes. If your web service performs a database operation that takes longer than five minutes, the transaction may time out before the operation is complete. One way to solve this problem is to use a data source that is not configured to be transactional. Another approach is to change the property that specifies the transaction timeout interval. The following code snippet shows how to set this property:

    import javax.transaction.Transaction;
    import weblogic.transaction.TxHelper;
    import weblogic.transaction.internal.TransactionImpl;
    ...
    Transaction tx = TxHelper.getTransaction();
    if (tx instanceof TransactionImpl)
        {
        ((TransactionImpl)tx).setProperty(weblogic.transaction.internal.Constants.TX_TIMEOUT_SECS_PROPNAME,
                        new Integer(nSeconds));
        }

For more information, see the following topics on e-docs.bea.com:

Managing Transactions

Programming Weblogic JTA

Related Topics

Transaction Basics