You can configure the transactional deployment descriptor attributes
associated with an EJB or Web module, to enable a J2EE application to use
transactions.
Before you begin
You must have an enterprise archive (EAR) file for an application
component that can be deployed in the application server.
About this task
You can configure the deployment attributes of an application
by using an assembly tool.
This topic describes the use of the Application
Server Toolkit to configure the deployment attributes of an application.
To
set transactional attributes in the deployment descriptor for an application
component (enterprise bean or servlet), complete the following steps.
Procedure
- Start the assembly tool. For information about starting
the Application Server Toolkit, refer to the Application Server Toolkit information
in the navigation pane of this information center.
- Create or edit the application EAR file. For example,
to change attributes of an existing application, use the Import wizard to
import the EAR file into the assembly tool. To start the Import wizard, use
the following steps:
- Click .
- Click Next, then select the EAR file.
- Click Finish.
- In the J2EE Hierarchy view, right-click the component instance,
then click . To locate the component
instance, use the appropriate step:
- For a session bean, expand ,
then select the bean instance.
- For a servlet, expand , then select the servlet instance.
A property dialog notebook for the deployment descriptor
of the component is displayed in the property pane.
- Optional: For session beans only, set the "Transaction
type" attribute, which defines the transactional manner in which the container
invokes a method. You can set this attribute to Container or Bean,
as follows:
- To use container-managed transactions, set the attribute to Container.
- To use bean-managed transactions, set the attribute to Bean.
- In the deployment descriptor notebook, select the Bean tab.
Optionally, in the WebSphere Extensions section, configure the Local Transaction
attributes. To enable management of local transaction containments,
configure the following component extensions attributes. These attributes
configure, for the component, the behavior of the container's local transaction
containment (LTC) environment that the container establishes whenever a global
transaction is not present.
- Boundary
This setting specifies the containment boundary at which all contained
resource manager local transactions (RMLTs) must be completed. Possible values
are BeanMethod or ActivitySession.
- Resolver
This setting specifies the component responsible for initiating and
ending RMLTs. Possible values are Application or ContainerAtBoundary.
- Application: This is the default value. The application is responsible
for starting RMLTs and for completing them within the local transaction containment
(LTC) boundary. Any RMLTs that are not completed by the end of the LTC boundary
are cleaned up by the container according to the value of the Unresolved action
attribute.
- ContainerAtBoundary: The container is responsible for starting RMLTs and
for completing them within the LTC boundary. The container begins an RMLT
when a connection is first used within the LTC scope, and completes it automatically
at the end of the LTC scope. If Boundary is set to ActivitySession, the RMLTs
are enlisted as ActivitySession resources and directed to complete by the
ActivitySession. If Boundary is set to BeanMethod, the RMLTs are committed
at the end of the method by the container.
- Unresolved action
Specifies the direction that the container requests RMLTs to take,
if those transactions are unresolved at the end of the LTC boundary scope
and the Resolver is set to Application. Possible values are Rollback or Commit.
- Rollback: This is the default value. At end of the LTC boundary scope,
the container instructs all unresolved RMLTs to roll back.
- Commit: At the end of the LTC boundary scope, the container instructs
all unresolved RMLTs to commit. The container instructs the RMLTs to commit
only in the absence of an un-handled exception. If the application method
that is running in the local transaction context ends with an exception, any
unresolved RMLTs are rolled back by the container. This is the same behavior
as for global transactions.
- In the WebSphere Extensions section, configure the Global Transaction
attributes. These attributes configure, for the component, behavior in the
presence of a global transaction.
- Component Transaction Timeout
- For enterprise beans using container-managed transactions only, specifies
the transaction timeout, in seconds, for any new global transaction that the
container starts on behalf of the enterprise bean. For transactions started
on behalf of the component, the Component Transaction Timeout setting overrides
the default total transaction lifetime timeout that is configured in the transaction
service settings for the application server.
The following attributes enable WS-AtomicTransaction
and WS-BusinessActivity support for Java API for XML-based RPC (JAX-RPC) applications:
- Use Web Services Atomic Transaction
- For enterprise beans only, when this attribute is selected, if the application
component makes any Web service requests, any transaction context is propagated
with the Web service requests in accordance with the WebSphere WS-AtomicTransaction
support described in Web Services Atomic Transaction support in WebSphere Application Server.
When this attribute is not selected, Web service requests do not carry transaction
context.
- Send Web Services Atomic Transaction on requests
- For Web components only, when this attribute is selected, if the application
component makes any Web service requests, any transaction context is propagated
with the Web service requests in accordance with the WebSphere WS-AtomicTransaction
support described in Web Services Atomic Transaction support in WebSphere Application Server.
When this attribute is not selected, Web service requests do not carry transaction
context.
- Execute using Web Services Atomic Transaction on incoming requests
- For Web components only, when this attribute is selected, Web application
components are prepared to run under a received WS-AtomicTransaction context.
A Web application component can run under a received WS-AtomicTransaction
context in a similar way to an enterprise bean deployed with a container transaction
type of Supports. When this attribute is not selected, the container of the
Web application component suspends any received transaction context, in a
similar way to the behavior of an EJB container for an enterprise bean deployed
with a container transaction type of NotSupported.
If your application uses
JAX-WS, enable support for WS-AtomicTransaction by creating a policy set,
adding the WS-Transaction policy type to the policy set, and attaching the
policy set to the service or client. WS-BusinessActivity is not supported
for JAX-WS applications.
If a policy
set that is attached to a client includes the WS-Transaction policy type,
any active global transaction context is propagated with a Web service request,
in a similar way to the deployment descriptors Use Web Services Atomic Transaction
and Send Web Services Atomic Transaction on requests, described earlier in
this topic. Also, when the WS-Transaction policy type is included, the service
runs under any received WS-AtomicTransaction context, in a similar way to
the deployment descriptor Execute using Web Services Atomic Transaction on
incoming requests, described earlier in this topic.
- For EJB components only, for container-managed transactions, configure
how the container manages the transaction boundaries when delegating a method
invocation to the business method of an enterprise bean:
- In the deployment descriptor notebook, select the Assembly tab.
The Container Transactions section displays a table of the methods for
enterprise beans.
- For each method of the enterprise bean, set the container transaction
type to an appropriate value. The default value for the container
transaction type is Required, meaning that the method invocation occurs in
the context of a transaction. This transaction is either the (local or remote)
client component's transaction or, if the client component does not run in
a transaction, a new transaction started by the component's container.
If the application uses ActivitySessions, how the container manages
transaction boundaries when delegating a method invocation depends on both
the container transaction type that you set in this task, and the ActivitySession
kind attribute, which is described in Setting EJB module ActivitySession deployment attributes. For more detail about the relationship
between these two properties, see ActivitySession and transaction container policies in combination.
- For Web services applications that use a SOAP/JMS binding and participates
in WS-AtomicTransactions, set the container transaction type of the message-driven
bean named "JMS router MDB" to a value of NotSupported, as described
in the previous step. Web service applications that use a SOAP/JMS
binding include a router message-driven bean named "JMS router MDB" in
the assembled EAR. If a Web service uses a SOAP/JMS binding and participates
in WS-AtomicTransactions, as described in Web Services Atomic Transaction support in WebSphere Application Server,
set the container transaction type of the "JMS router MDB" to a value
of NotSupported.
For Web services applications that use a SOAP/HTTP binding
and participate in WS-AtomicTransactions, you do not need to do this.
- For client application components only, if required, enable support
for transaction demarcation by the client. In the deployment descriptor
notebook, select the Allow JTA demarcation check box.
This option directs the client container to bind the Java Transaction API
(JTA) UserTransaction interface into JNDI at java:comp/UserTransaction for
the client component. There are constraints on transaction support in the
client container, which are described in Client support for transactions.
- Save your changes to the deployment descriptor.
- Close the deployment descriptor editor.
- When prompted, click Yes to save changes
to the deployment descriptor.
- Verify the archive files. For more information about
verifying files using the Application Server Toolkit, refer to the Application
Server Toolkit information in the navigation pane of this information center.
- From the menu of the project, click Deploy to
generate EJB deployment code.
- Optional: Test your completed module on an application
server installation. Right-click a module, click Run on Server,
and follow the instructions in the resulting wizard.
Important: Use
the Run On Server option for unit testing only. The
assembly tool controls the application server installation, and when an application
is published remotely, the assembly tool overwrites the server configuration
file for that server. Do not use the Run On Server option
on production servers.
What to do next
After assembling your application, use a systems management tool,
for example the administrative console, to deploy the EAR file onto the application
server that is to run the application.