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 support:
- 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.
- 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.