Anda di halaman 1dari 35

IBM Software Group

Transactional Capabilities of
WebSphere Application Server

David Currie, IT Specialist


EMEA Software Lab Services

© 2005 IBM Corporation

1
IBM Software Group

Agenda

ƒ J2EE transaction basics


ƒ WebSphere Application Server specifics
ƒ New for Version 6

2 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

This presentation will begin by looking at some of the basics of transactions in the
J2EE environment. We will then take a look at some of the additional capability
provided by WebSphere Application Server including some of those that were
previously only available as programming model extensions. Finally, we will cover
functionality that is new in Version 6.

2
IBM Software Group

What is a transaction?

ƒ Collection of operations on the physical and abstract application


state exhibiting the ACID properties
ƒ Atomicity – either all operations happen or none
ƒ Consistency – integrity constraints on the state are maintained
ƒ Isolation – transactions execute concurrently but to each it
appears that they are executed serially
ƒ Durability – once transaction completes successfully, state
changes survive failures

Transaction Processing : Concepts and Techniques

3 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

Typical example of a transaction is a bank transfer with debit and credit operations.
Transaction should be atomic so that either both the debit and credit take place
or neither do. If the transaction is consistent then the money debited and the
money credited are equal. For isolation to hold, the transaction should be
unaware of other operations taking place on the account. Once the transaction
is complete, durability ensures that the balance continues to reflect the updated
amount.

3
IBM Software Group

J2EE architecture

JDBC
EJB Resource
Application Servlet Container JMS
JCA Manager

4 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The application (EJB, servlet or JSP) running in the container of a J2EE application
server makes use of services via interactions defined in the EJB and Servlet
specifications. Through the application server, the application may also obtain
access to resources external to the application server e.g. databases, messaging
systems or other EIS. From our definition of a transaction, the application state is
being held by the resource manager and the operations are performed by the
application via operations on the JDBC, JMS or JCA interfaces.

4
IBM Software Group

Resource manager local transactions (RMLT)

ƒ Enable coordination of operations on a single resource manager


ƒ JDBC
– Connection.setAutoCommit(false)
– Connection.commit/rollback
ƒ JMS
– Connection.createSession(true, Session.AUTO_ACKNOWLEDGE)
– Session.commit/rollback
ƒ JCA CCI (e.g. CICS ECI RA)
– Connection.getLocalTransaction()
– LocalTransaction.begin/commit/rollback

5 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

A resource manager local transaction (RMLT) enabled operations on a single


resource manager to be coordinated. The default behaviour of most resource
managers is typically to perform operations independently (‘auto-commit’) and
therefore have some mechanism to indicate that operations should be grouped into
local transactions. Each API then provides methods to demarcate the transaction.
In the case of JDBC and JMS, there is no ‘begin’ method as the specifications
define that one local transaction begins automatically when the previous one ends.

5
IBM Software Group

Global (XA) transactions

ƒ Enable coordination of operations on multiple resource managers


ƒ Transactions demarcated by the application (Bean Managed
Transactions) or the container (Container Managed Transactions)
ƒ Java Transaction API defines interfaces between application,
server and resource manager
ƒ Based on industry standard X/Open CAE Specification
(Distributed Transaction Processing: The XA Specification)
ƒ Supported by most JDBC/JMS providers and some JCA resource
adapters e.g. CICS IMS for Java 2.2.2

6 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

In contrast, a global transaction enables operations to be coordinated across


multiple resource managers. Global transactions may be demarcated by the
application (BMT) or the container (BMT). The Java Transaction API defines the
interfaces between the application, server and resource manager necessary to
perform the coordination. The protocol between the server and resource manager
is based on the industry standard XA specification. Most JDBC and JMS providers
support XA transactions as do many JCA resource adapters.

6
IBM Software Group

Java Transaction API

JDBC
EJB Resource
Application Servlet Container JMS
JCA Manager

Java Transaction API XAResource

UserTransaction TransactionManager/Transaction

Java Transaction Service

7 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The Java Transaction Service is a rendering of the CORBA Object Transaction


Service in Java. The Java Transaction API defines the interfaces implemented by
the transaction service and used by the application and/or container to demarcate
transaction. It also defines the interface implemented by the Resource Manager to
support global transactions.

7
IBM Software Group

Bean Managed Transactions

ƒ Example EJB/servlet code:


InitialContext context = new InitialContext();
UserTransaction ut = (UserTransaction)
context.lookup(“java:comp/UserTransaction”);
ut.begin();
jdbcStatement.execute(query);
jmsMessageProducer.send(message);
jdbcConnection.close();
jmsSession.close();
ut.commit();

8 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The example shows how and EJB or servlet obtains an instance of the transaction
services’ UserTransaction from JNDI. (In an EJB environment the UserTransaction
can also be obtained from the EJB context.) The application invokes the begin
method to start the global transaction. The work performed by the JDBC and JMS
providers will then be a part of that transaction. The application then decides
whether to commit or rollback the transaction. Once a global transaction has
started, it is not possible to perform a local transaction. Similarly, if there is
outstanding local transaction work, it is not possible to begin a global transaction.
The UserTransaction interface also has methods for setting the transaction timeout,
getting the current status of the transaction currently associated with the thread and
marking the current transaction so that it will be rolled back on completion.

8
IBM Software Group

XA protocol : enlistment

JDBC
3. getXAResource()

JDBC
2. execute()
6. execute() JDBC
Container 8. getXAResource() Resource

XAResource
7. send() Manager

JMS
11. send()5. start()

4. enlistResource()
9.

Application

JMS
Transaction
JMS
UserTransaction

Java Resource

XAResource
1. begin()
Transaction
10. start()
Manager
Service

9 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

This diagram (when animated) shows the steps involved in starting a transaction
and then enlisting a JDBC and JMS resource. Note that the container intercepts the
calls to the JDBC/JMS APIs in order to perform the transaction enlistment. There is
a separate XAResource instance associated with each JDBC connection/JMS
session so that the resource manager knows that subsequent work should be
associated with the transaction represented by the Xid passed on the start.

9
IBM Software Group

XA protocol : completion

JDBC
15. close()

JDBC
12. close()
JDBC
Container 19. close()
21. prepare() Resource

XAResource
Manager

JMS
16. close() 14. end()

13. delistResource()
17.
Application

JMS
Transaction
JMS
UserTransaction

Java Resource

XAResource
20. commit() 23. commit()
Transaction 18. end()
Manager
22. prepare()
Service 24. commit()

10 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

When the application closes the resource, the transaction service will call end on
the XAResource ending the association between the resource and the transaction
(although in WAS the resource will not be reused until the transaction completes).
When the application commits the transaction, the transaction service asks each
XAResource in turn to prepare. The resource manager responds to indicate
whether or not it is prepared to complete the transaction successfully. If a resource
manager votes XA_OK then it must then be prepared to commit the transaction.
(The resource manager can also respond XA_RDONLY if it has not performed any
work as part of the transaction in which case it will not receive a completion call.)
Once all of the resource managers have responded, the transaction service logs the
outcome so that, if the server should fail after delivering the result to one or more
resource managers, it can deliver the same result to the other resource managers
on recovery. The prepare and commit/rollback are the two phases of the 2-phase
commit.
If only one resource manager is involved then the prepare can be skipped resulting
in a 1-phase commit.

10
IBM Software Group

Container Managed Transactions

ƒ Container demarcates transactions at method boundaries based


on attributes specified in deployment descriptor
– Required
– RequiresNew
– Supports
– NotSupported
– Mandatory
– Never
ƒ Protocol is as for BMT except that container starts/completes the
transaction using the TransactionManager interface

11 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The application developer may alternatively specify in the application’s deployment


descriptor that the container should manage the demarcation of transactions. In
this case, the developer specifies on each EJB/servlet method or bean a transaction
attribute that determines the container’s behaviour:
•Required – if there isn’t already a transaction associated with the thread, start one
•RequiresNew – start a new transaction, suspending any existing transaction
•Support – use the current transaction on the thread if there is one
•NotSupported – suspend the current transaction on the thread if there is one
•Mandatory – there must already be a transaction associated with the thread before
the method is invoked
•Never – there must not be a transaction associated with the thread before the
method is invoked
The XA protocol is identical to that for bean managed transactions except that the
container uses the JTA TransactionManager interface to drive the
begin/commit/rollback. Note that, for a CMT bean, the UserTransaction interface
cannot be used. Also, as with the BMT case, a local transaction cannot be used if a
global transaction has been started.

11
IBM Software Group

Distributed transactions

ƒ Transactions may be propagated from one server (the superior)


to another (the subordinate) via a remote EJB invocation
– Transaction service attaches context to RMI/IIOP request
– Subordinate registers as a resource with the superior for
inclusion in two-phase commit protocol
ƒ Transactions may also be imported into a server via the JCA 1.5
transaction inflow contract
– Resource adapter drives transaction completion and recovery
via XATerminator interface

12 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

Transactions may be propagated from one J2EE server to another via a remote
EJB invocation. The transaction service on the requesting server attaches
transaction context to the RMI/IIOP request. On receiving this, the subordinate
transaction coordinator will register with the superior coordinator as a resource so
that it is included in the final two-phase commit protocol. Transactions may also be
imported in to a WAS 6 server via the new JCA 1.5 transaction inflow contract. In
this case, the resource adapter is responsible for driving transaction completion and
recovery via the XATerminator interface. As we shall see later, transactions may
also be distributed via Web service requests.

12
IBM Software Group

Agenda

ƒ J2EE transaction basics


ƒ WebSphere Application Server specifics
ƒ New for Version 6

13 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

We shall now look at some of the transaction capabilities specific to WebSphere


Application Server.

13
IBM Software Group

Last participant support

ƒ Enables a single one-phase capable resource to be


involved with one or more XA resources in the same
global transaction
ƒ Support is enabled on a per application basis
ƒ Transaction service can be configured to perform
additional logging of the decision to commit or rollback
the one-phase resource

14 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

In WAS 5 it was possible to use a single one-phase capable resource in a global


transaction providing no other resources were enlisted. Last participant support is a
programming model extension from WAS 5 that enables one or more XA resources
to be enlisted in the same global transaction as the one-phase capable resource.
On transaction completion, the transaction service will begin by preparing all of the
XA resources. It will then attempt to commit the one-phase capable resource and,
depending on the outcome, complete the XA resources in the appropriate direction.
The support is enabled on a per application basis.
Using last participant support increases the risk of a heuristic outcome as, if the
completion of the one-phase resource times out, the transaction service does not
know in which direction to complete the transaction. The transaction service can be
configured to log the decision as to whether the one-phase resource is to be
committed or rolled back. If failure occurs then, on recovery, if a rollback was to
performed the transaction may be rolled back consistently. If a commit was to be
performed then a heuristic outcome is reported in the activity log.

14
IBM Software Group

Local Transaction Containment (LTC)

ƒ Container provides scoping boundary for resource manager local


transactions
ƒ Always present in the absence of a global transaction
ƒ Boundary of scope may be:
– Bean method (default)
– Activity session
ƒ Control over the resolution of local transactions may lie with:
– Application (default)
– ContainerAtBoundary

15 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

WAS introduced the concept of a local transaction containment (LTC) which is


always present in the absence of a global transaction (it fills the gaps that the
specifications define as an ‘unspecified transaction context’) and can be used to
scope resource manager local transactions. The boundaries of the scope may be a
bean method (the default) or an activity session. We will look at activity sessions
later so, for the moment, we will concentrate on the bean method scoping. Control
over the resolution of the local transactions scoped by the LTC may lie with the
application (the default) or the container. These options (boundary and resolution-
control) are specified in the application’s deployment descriptor extensions.

15
IBM Software Group

Application resolution control

ƒ Incomplete local transactions are ended in the direction of the unresolved action
at end of scope (default is to roll back)

public void componentMethod() // LTC begins here


{

Connection connection = connectionFactory.getConnection();


LocalTransaction localTran = connection.getlocalTransaction();

localTran.begin(); // RMLT begins here

// create interaction and execute


localTran.commit(); // RMLT ends here


} // LTC ends here

16 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

When the application is responsible for resolving local transactions, the LTC is only
used to complete any local transactions that have not been completed at the end of
the scope. In this example of a method scoped LTC, if the commit was omitted or
an exception caused the method to exit before it was reached, then the container
would instruct the resource manager to complete its local transaction in the direction
of the unresolved action. The unresolved action is specified in the deployment
descriptor extensions and the default is to rollback the transaction. This ensures
that local transactions are always completed. Note that this implies that, when
using the bean method scoping, a resource manager local transaction cannot have
a lifetime greater than the method in which it was started. Also note that, if another
method on a component interface is invoked, a new LTC is begun (c.f.
RequiresNew for a global transaction).

16
IBM Software Group

ContainerAtBoundary resolution control

ƒ Container begins local transaction for each resource manager


and completes them all at end of scope
ƒ WAS 6 also supports ContainerAtBoundary in the web container

public void componentMethod() // LTC begins here


{

Connection cciConnection = connectionFactory.getConnection(); // RMLT begins


Interaction interaction = cciConnection.createInteraction();
Record result = interaction.execute(interactionSpec, input);

Connection jdbcConnection = dataSource.getConnection(); // RMLT begins


Statement statement = jdbcConnection.createStatement();
statement.execute(query);

} // LTC ends here and completes RMLTs

17 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The alternative is that the container is responsible for resolving the local
transactions. The behaviour here is similar to a CMT global transaction in that the
application does not begin the local transactions explicitly. Instead, the container
instructs the resource manager to start a local transaction when a connection is
obtained. When the LTC ends, the container will then complete all of the local
transactions. For an LTC scoped by a bean method, the container will attempt to
commit the transaction unless an exception has been thrown in which case it will be
rolled back (as per a global transaction). This mechanism therefore enables
multiple non-XA capable resource managers to be loosely coordinated. The
coordination is ‘loose’ because the lack of a prepare phase means that the
container cannot guarantee that all resource managers will be prepared to commit
the local transaction.

In WAS 6, the use of ContainerAtBoundary has been extended from the EJB
container to the web container.

17
IBM Software Group

Activity sessions

ƒ Activity sessions extend the semantics of LTC to


provide applications using one-phase resource
managers functionality similar to global transactions
ƒ Management type defined in deployment descriptor
extension:
– Bean
– Container

18 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

As described above, by default, a LTC is scoped by a bean method thereby limiting


the extent of a resource manager local transaction. Activity sessions enable that
scope to be extended across multiple components giving application using one-
phase capable resource managers functionality similar to that they would have if
using global transactions. As with global transactions, activity sessions many be
managed by the bean or by the container.

18
IBM Software Group

Bean managed activity session

ƒ UserActivitySession obtained via JNDI lookup from


java:comp/websphere/UserActivitySession
ƒ Transaction demarcation:
– beginSession
– endSession(EndModeCheckPoint)
– endSession(EndModeReset)
ƒ Mid-session:
– checkpointSession
– resetSession
ƒ Also: setResetOnly, getStatus, get/setSessionTimeout

19 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

For a bean managed activity session, a UserActivitySession can be obtained from


JNDI in a similar manner to a UserTransaction. Ending a session with a checkpoint
corresponds to a commit and ending with a reset corresponds to a rollback. It is
also possible to perform a checkpoint midway through an activity session. This
completes any local transactions at this point but the activity session continues.
The setResetOnly method is analogous to setRollbackOnly.

19
IBM Software Group

Container managed activity session

ƒ Deployment descriptor extensions determine kind of activity


session on a per method basis:
– Required
– RequiresNew
– Supports
– NotSupported
– Mandatory
– Never

20 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

Similarly, for a container managed activity sessions, the kind of activity session can
be specified on a per method basis in much the same way as for global transaction
attributes.

20
IBM Software Group

Activity session example


EJB container
Activity Session
RMLT 1

1PC
Database A
EJB container

Session Bean
AS RequiresNew 1PC
Database B

RMLT 2

Entity Beans
ContainerAtBoundary
AS Requires
21 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

This example illustrates the use of an activity session. A session bean invokes two
entity beans which perform database updates however, in this scenario, the two
databases are not XA capable. By default, the two updates would happen auto-
commit. By applying a resolution-control of ContainerAtBoundary, a local
transaction is started for each entity bean but is completed at the end of the
method. The beans are then configured to use container managed activity sessions
with the session bean having a kind of RequiresNew and the entity beans Requires.
The local transactions will then be completed together when the session bean
method completes. Note that, if the application was to request multiple connections
to one of the databases, the connection manager would ensure that the same
underlying connection was used so that there would still only be one local
transaction per database.

In the web container, an activity session can be scoped to a HttpSession. This


enables, for example, an application to perform some work under a local transaction
on one request and then commit it or roll it back on a subsequent request.

Also, activity sessions can be used to extend the lifecycle of an EJB. By setting the
activation policy to ACTIVITY_SESSION, the bean instance will not be passivated
until the activity session completes.

21
IBM Software Group

ExtendedJTATransaction interface

ƒ ExtendedJTATransaction interface can be looked up from JNDI


at java:comp/websphere/ExtendedJTATransaction
ƒ Enables callbacks for notification of transaction completion
– register/unregisterSynchronizationCallback
– registerSynchronizationCallbackForCurrentTran
ƒ Determine transaction identity
– getLocalID
– getGlobalID
ƒ Available in all J2EE components

22 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The ExtendedJTATransaction interface is a programming model extension from


WAS 5. It enables any J2EE application component to determine the identity of the
current transaction and register synchronizations to be informed of transaction
completion. The SynchronizationCallback interface is notified before completion
with the local and global identity of the transaction and after completion with the
same information plus an indication of whether the completion was successful. The
local ID is a unique integer within the current process and the global ID is a byte
array containing the XA transaction ID. The “Transaction tracker” sample
demonstrates this functionality.

22
IBM Software Group

Performance metrics

ƒ Basic ƒ All – extended plus:


– ActiveCount – LocalCommittedCount
– RolledbackCount – LocalRolledbackCount
– CommittedCount – GlobalInvolvedCount
ƒ Extended – basic plus: – OptimizationCount
– GlobalTimeoutCount – LocalActiveCount
– GlobalBegunCount
– GlobalBeforeCompletionTime
– LocalBegunCount
– LocalBeforeCompletionTime
– LocalTranTime – GlobalCommitTime
– GlobalTranTime – LocalCommitTime
– GlobalPrepareTime

23 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

This slides presents a list of all of the transaction-related statistics which can be monitored using Performance Metrics and
under which set each statistic lies. Each statistic set is a super-set of its predecessor: extended includes all of basic, and all
includes all of extended. Under each set the statistics have been grouped according to their type; those that provide an
overall count followed by those that provide an average time duration for a particular operation to complete.

ActiveCount: The number of global transactions currently active on the server


RolledbackCount: The total number of global transactions that have rolled back
CommittedCount: The total number of global transactions that have committed

GlobalTimeoutCount: The total number of global transactions that have timed out
GlobalBegunCount: The total number of global transactions that have been begun
LocalBegunCount: The total number of local transactions that have been begun

LocalTranTime: The average duration of a local transaction


GlobalTranTime: The average duration of a global transaction

LocalCommitedCount: The total number of local transactions that have committed


LocalRolledbackCount: The total number of local transactions that have rolled back
GlobalInvolvedCount: The total number of transactions (both begun on-server and imported) with which the server has been
involved
OptimizationCount: The total number of global transactions that have been completed using a one-phase commit
optimization
LocalActiveCount: The number of local transactions currently active on the server

GlobalBeforeCompletionTime: The average duration of before completion processing of a global transaction


LocalBeforeCompletionTime: The average duration of before completion processing of a local transaction
GlobalCommitTime: The average duration of commit processing of a global transaction
LocalCommitTime: The average duration of commit processing of a local transaction
GlobalPrepareTime: The average duration of prepare processing of a global transaction

23
IBM Software Group

Performance metrics example

24 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

This slide shows an example graph of the some of the extended statistics as
displayed by Tivoli Performance Viewer.

24
IBM Software Group

Transaction administration

ƒ Imported prepared transaction


– Manual commit/rollback
ƒ Retry transactions
– Manual finish
ƒ Heuristic transactions
ƒ Manual transactions
– Manual commit/rollback

25 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

Transactions which have been imported in to the server and then prepared can be viewed. These
may be committed or rolled back manually but, if the decision is different to that taken by the external
transaction manager then the outcome will not be atomic.

Retry transactions are those in which the transaction manager has prepared the transaction but is
now unable to contact one or more resource managers. The number and frequency of retry attempts
is determined by the “Heuristic retry limit” and “Heuristic retry wait” defined on the transaction
service. (The default is to retry indefinitely, doubling the wait time every 10 attempts.) The
administrator can instruct the transaction manager to abandon retrying.

Heuristic transactions provides a list of the transactions that have completed heuristically. For
example, the resource manager has responded to a completion request with a failure or the
transaction manager has exceeded the retry limit and the transaction service was configured to
commit or rollback the transaction in this case. The administrator can clear transactions from the list
once they have been reviewed.

The transaction service can be configured to leave heuristic transactions for manual completion by
an administrator. The administrator can commit or rollback each transaction.

In each case you can chose to display the resources (or at least the resource managers) associated
with the transaction.

25
IBM Software Group

Agenda

ƒ J2EE transaction basics


ƒ WebSphere Application Server specifics
ƒ New for Version 6

26 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

26
IBM Software Group

Transaction timeouts

ƒ Now four transactional timeouts:


– Total Transaction Lifetime Timeout (default 120s)
– Maximum Transaction Timeout (default 0 = infinite)
– Client Inactivity Timeout (default 60s)
– Component Transaction Timeout (default 0 = total tran timeout)
ƒ On timer expiry the transaction is marked for rollback which then
takes place the next time the container is involved (e.g. end of
method)

27 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

•Total Transaction Lifetime Timeout - the total time a transaction can live for,
starting from the moment the begin method is called till it enters the completion
process
•Maximum Transaction Timeout – the maximum timeout value an application server
will accept for an imported transaction context
•Client Inactivity Timeout – the time a subordinate will wait after performing work
under a transaction context
•Component Transaction Timeout – used by a CMT bean which has transactions
begun by the container (defined on deployment descriptor)

27
IBM Software Group

Rollback propagation

ƒ When a transaction is marked as rollback only and WAS V6 is


acting as a subordinate, it will attempt to inform its superior
ƒ Enables the transaction to be rolled back cleanly
ƒ If the superior is not at the required level then it will not
understand the request and, when the superior attempts to
commit the transaction, the subordinate then will throw a rollback
exception

28 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The following maintenance levels are required for propagation to be successful:


•V4.0 – PQ88648
•V5.0.2.8 – PQ89426
•V5.1.1.2 – PQ89425 (5.1.0.4) and PQ84384 (5.1.1.2)

28
IBM Software Group

Client transactions

ƒ Enables client container applications to begin and complete


transactions containing work performed on the server-side
ƒ UserTransaction obtained from JNDI
ƒ Must be enabled in client deployment descriptor

ƒ Work performed in the client container is not part of the


transaction

29 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

Applications running in the WAS client container may now, if enabled in their
deployment descriptor, obtain a UserTransaction instance from JNDI. This
UserTransaction may be used to demarcate a transaction that is propagated to
server-side requests. This enables, for example, a client to invoke two separate
EJBs under a single transaction. (My preference would be to implement a stateless
session bean to encapsulate this logic but there may be scenarios where this is not
possible.) Note that any work performed in the client container (e.g. JMS or JDBC
calls) is not part of the transaction.

29
IBM Software Group

Transaction service high availability

8
Cluster
server1

Txn Log

server2

Txn Log

server3

Txn Log

30 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

This diagram shows three servers in a cluster accessing records in a database


transactionally. The colours in the database represent rows or tables locked under
a transaction coordinated by the server of the matching colour. When server1 fails,
it leaves indoubt transactions in the database. These locks may eventually prevent
processing continuing in the other servers in the cluster. In previous versions of
WAS, it would have been necessary to wait until server1 restarted before
transaction recovery could take place and the locks be released. In WAS 6, it is
possible to enable high availability for persistent services running in the cluster. The
HA manager will notify the transaction service in one of the other servers that it
should perform transaction recovery for server1. The indoubt transactions will then
be committed or rolledback, releasing the locks in the database. The server does
not take over processing from server1 and once recovery is complete the logs are
released.

30
IBM Software Group

Transaction service HA configuration

ƒ Enable “High availability for persistent services” on cluster


ƒ Configure recovery log location for each server with path
accessible from every server
– Network Attached Storage device mounted via NFS4
ƒ HA policy can be modified for more advanced configuration

31 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

High availability is configured by enabling an option on the cluster. The transaction


log directory on each server must then be configured with a path that is addressable
from every other server in the cluster. For example, “/logs/server1” where every
server has a mount “logs”. The HA manager may cause activation in other
undesirable circumstances (e.g. server under heavy load or network partitioned) in
which case the recovery log service relies on file locks to prevent peer recovery
when the original server is still running. Unfortunately, the file locking in NFS3
prevents recovery even when the original server is down. In this case, the
recommended approach is to initiate recovery manually. (File locking can be
disabled providing system overload or network partitioning will not occur.)
Reference at end of presentation provides more detailed information on modifying
the HA policy.

31
IBM Software Group

WS-AtomicTransaction (WS-AT)

ƒ Provides distributed two-phase commit transaction


support for Web services
ƒ Specifications published jointly by IBM, Microsoft and
BEA in November 2004
ƒ Defines participant and coordinator and the message-
sets that they exchange (based on existing protocols:
XA, OTS and Activity service)

32 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

WS-AtomicTransaction is part of the WS-Transaction family of specifications. WS-


Coordination provides a framework for protocols that coordinate the action of
distributed applications enabling agreement on an activity outcome. WS-
AtomicTransaction supports short-lived, two-phase commit transactions while WS-
BusinessActivity covers long-running transactions and capabilities such as
compensation.

32
IBM Software Group

WS-AT distributed transactions


WAS SOAP/HTTP .NET
SOAP/JMS
SIBus
Send request: Tx ID

Register resource
Transaction Transaction
Service Service
Receive reply

Prepare/commit - asynchronous

SOAP/HTTP

33 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

The flows involved in distributing a transaction using WS-AT between WAS and, for example, .NET
follow an identical pattern to those made in JTS-based interoperability. Information about the
transaction is included in the outbound Web Service request and is extracted from the request by the
target server. The subordinate then makes a registration call back to its superior to establish a link
between the two servers before the request is completed by the sending of a reply message.

The one major difference between WS-AT and IIOP-based distribution is that the protocol messages
sent from the superior to its subordinates during transaction completion (prepare, commit, and
rollback) are made asynchronously. For example the superior will send a one-way prepare message
to each WS-AT subordinate and will then block for a maximum of 30 seconds or until a one-way
response to the prepare request has been received from each subordinate. Once all of the responses
have been received the superior will commit or rollback the transaction as appropriate.

There are three separate transports over which WS-AT context can be sent: SOAP-HTTP, SOAP-
JMS, and SIBus. In each case the general behavior and flows involved are unchanged however it is
worth noting that irrespective of the transport over which the WS-AT context was sent all of the
coordination protocol messages (subordinate registration with its superior, prepare, commit, and
rollback) will be sent using SOAP-HTTP.

If two WAS servers are communicating then there is no separate registration call made from the
subordinate to the superior. This registration is piggy-backed onto the reply message that’s sent
when the Web service request completes.

33
IBM Software Group

WS-AT configuration

ƒ No application code changes required – just changes to deployment


descriptors
ƒ Web service clients (outbound)
– EJBs : “Use Web Services Atomic Transaction”
– Servlets : “Send Web Services Atomic Transactions on requests”
ƒ Web service implementations (inbound)
– Servlets : “Execute using Web Services Atomic Transaction of
incoming request”
– EJBs standard EJB transaction deployment descriptors are used

34 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

To utilize WS-AT no changes to application code are required. However, to have


existing Web service clients and implementations send and receive WS-AT
transaction context, some deployment descriptors changes are necessary.

To cause WS-AT context to be included in an outbound Web service request the


Web Service client must indicate that it should be propagated on the request. EJB-
based Web service clients should check the “Use Web Services Atomic
Transaction” checkbox in the Global Transaction section of the EJB’s deployment
descriptor. Servlet-based Web service clients should check the “Send Web
Services Atomic Transactions on requests” checkbox in the Global Transaction
section of the Servlet’s deployment descriptor.

It is also possible to control whether or not a Web Service implementation should


run under a transaction that has been received via WS-AT. For a Servlet-based
Web service implementation the “Execute using Web Services Atomic Transaction
of incoming request” checkbox should be enabled. For EJB-based Web service
implementations the standard transactional attributes on the EJB’s method should
be used instead. For example, to mandate that the Web service must run under a
transaction received via WS-AT a container-managed transaction type of Mandatory
would be appropriate whereas to reject any Web service requests that include
transactional context Never would be appropriate.

34
IBM Software Group

References

ƒ Learn about transactions in WebSphere Application Server


– http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?
topic=/com.ibm.websphere.nd.doc/info/ae/ae/
welc6tech_jta_links.html
ƒ Transactional high availability and deployment considerations in
WebSphere Application Server V6
– http://www-128.ibm.com/developerworks/websphere/
techjournal/0504_beaven/0504_beaven.html
ƒ WS-AtomicTransactions
– http://www-128.ibm.com/developerworks/library/
specification/ws-tx/

35 Transaction Capabilities of WebSphere Application Server 28 June 2005 © 2003 IBM Corporation

35