Set transactional deployment attributes

Set transactional deployment attributes

+
Search Tips | Advanced Search

Configure the transactional deployment descriptor attributes associated with an EJB or Web module, to enable an enterprise application to use transactions.
You must have an EAR file for an application component that can be deployed in the appserver.
Configure the deployment attributes of an application by using an assembly tool.
This page describes the use of Rational Application Developer to configure the deployment attributes of an application.
To set transactional attributes in the deployment descriptor for an application component (enterprise bean or servlet)...

Start the assembly tool.
Create or edit the app EAR file.
For example, to change attributes of an existing application, use the Import wizard to import the EAR file into the assembly tool...
File | Import | EAR file | Next | EAR_file | Finish

In the Project Explorer view of the Java EE perspective, right-click the component instance, then click...

Open With | Deployment Descriptor Editor

To locate the component instance, use the appropriate step:

For a session bean, expand...

EJB Modules | ejb_module_instance | Deployment Descriptor | Session Beans | bean_instance

For a servlet, expand...

Web Modules | web_application | Deployment Descriptor | web component | servlet_instance.

A property dialog notebook for the deployment descriptor of the component is displayed in the property pane.
For session beans only, set the "Transaction type" attribute to one of the following...

Container
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 LTC environment that the container establishes whenever a global transaction is not present.

Boundary

Containment boundary at which all contained resource manager local transactions (RMLTs) must be completed. Possible values are...

BeanMethod Default value. If selected, RMLTs must be resolved within the same bean method in which they were started.
ActivitySession RMLTs must be resolved within the scope of any ActivitySession in which they were started or, if no ActivitySession context is present, within the same bean method in which they were started. The ActivitySession option is not supported in the Web container. For EJB components only

Resolver

Component responsible for initiating and ending RMLTs. Possible values are...

Application Default value. The application is responsible for starting RMLTs and for completing them within the 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

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 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 app method 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.

Shareable

Whether the component can share an LTC. A new LTC is started only if a shareable LTC does not already exist. Applications that use shareable LTCs cannot explicitly commit or roll back resource manager connections that are used in a shareable LTC (although they can use connections that have an autoCommit capability).
If an application starts any non-autocommit work in an LTC for which the Resolver attribute is set to Application, and the Shareable attribute is set to true, an exception is thrown at run time.
For example, on a JDBC Connection, non-autocommit work is work that the app performs after using the setAutoCommit(false) method to switch off the autocommit option on the connection. Enterprise beans that use bean managed transactions cannot be assembled with the Shareable attribute set on the LTC configuration.
You must specify the Shareable attribute for all components that share the LTC. The component that creates the shareable LTC determines the other properties of the shared LTC, for example the value of the Resolver attribute.

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, this setting overrides the default total transaction lifetime timeout configured in the transaction service settings for the appserver.

The following attributes enable WS-AtomicTransaction and WS-BusinessActivity support for JAX-RPC applications only:

Use Web Services Atomic Transaction

For enterprise beans only. For Web service requests the transaction context is propagated in accordance with WS-AtomicTransaction.
If not selected, Web service requests do not carry transaction context.

Send Web Services Atomic Transaction on requests

For Web components only. For Web service requests the transaction context is propagated in accordance with WS-AtomicTransaction.
If not selected, Web service requests do not carry transaction context.

Execute using Web Services Atomic Transaction on incoming requests

For Web components only. If selected, Web app components are prepared to run under a received WS-AtomicTransaction context.
A Web app 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.
If not selected, the container of the Web app 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 the app uses JAX-WS, enable support for WS-AtomicTransaction or WS-BusinessActivity by...

creating a policy set
adding the WS-Transaction policy type to the policy set
attaching the policy set to the service or client

If a policy set 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 app uses ActivitySessions, how the container manages transaction boundaries when delegating a method invocation depends on both the container transaction type set in this task, and the ActivitySession kind attribute, which is described in Set 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.
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, , 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 have 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 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 the 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.
From the menu of the project, click Deploy to generate EJB deployment code.
Test the completed module on an application server installation. Right-click a module, click Run on Server, and follow the instructions in the resulting wizard.
Use the Run On Server option for unit testing only. The assembly tool controls the appserver 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.

Next steps

After assembling the app, use a systems management tool, for example the admin console, to deploy the EAR file onto the app server that is to run the app.

Related concepts
Assembly tools
Web Services Atomic Transaction support in the appserver

Related tasks
Set transaction properties for an appserver
Deploy enterprise apps
Create policy sets
Attach a policy set to a service artifact
Develop components to use transactions
Assembling applications

Related
ActivitySession and transaction container policies in combination
Local transaction containment considerations
Transaction service settings

Related information
Enterprise Java Beans specification WAS Development Best Practices for Performance and Scalability
Rational Application Developer documentation

BeanMethod	Default value. If selected, RMLTs must be resolved within the same bean method in which they were started.
ActivitySession	RMLTs must be resolved within the scope of any ActivitySession in which they were started or, if no ActivitySession context is present, within the same bean method in which they were started. The ActivitySession option is not supported in the Web container. For EJB components only

Rollback	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 app method 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.