Configure transactional deployment attributes
Use this task to configure the transactional deployment descriptor attributes associated with an EJB or Web module, to enable a J2EE application to use transactions. This task assumes that you have an EAR file for an application component that can be deployed in WAS. For more details about assembling applications, see Assembling applications.
Overview
You can configure the deployment attributes of an application by using an assembly tool.
This topic describes the use of the Application Server Toolkit (AST) 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 AST, refer to the Application Server Toolkit information in the navigation pane of this infocenter.
- 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:
- Click File-> Import-> EAR file
- Click Next, then select the EAR file.
- Click Finish.
- In the J2EE Hierarchy view, right-click the component instance, then click Open With > Deployment Descriptor Editor. For example:
- For a session bean, expand EJB Modules-> ejb_module_instance-> Deployment Descriptor-> Session Beans then select the bean instance.
- For a servlet, expand Web Modules-> web_application-> Deployment Descriptor-> web component then select the servlet instance.
A property dialog notebook for the component's deployment descriptor is displayed in the property pane.
- [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 Container
- To use bean-managed transactions, set Bean
- In the deployment descriptor notebook, select the Bean tab. Under WebSphere Extensions, optionally configure Local Transaction. 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 Bean method or ActivitySession.
- BeanMethod: This is the default value. If you select this option, RMLTs must be resolved within the same bean method in which they were started.
- [For EJB components only] 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 Webcontainer.
- 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 they 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 will instruct the RMLTs to commit only in the absence of an un-handled exception. If the application method executing under 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.)
- Continuing in WebSphere Extensions, configure Global Transaction. 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 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:
- 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 WAS. 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 WAS. 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 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; this is analogous to the Use Web Services Atomic Transaction and Send Web Services Atomic Transaction on requests deployment descriptors described above. The inclusion of the WS-Transaction policy type also causes the service to run under any received WS-AtomicTransaction context. This is analogous to the Execute using Web Services Atomic Transaction on incoming requests deployment descriptor described above.
- [For EJB components only] For container-managed transactions, configure how the container manages the transaction boundaries when delegating a method invocation to an enterprise bean's business method:
- In the deployment descriptor notebook, select the Assembly tab. The Container Transactions box 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 execute under 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 set in this task, and the ActivitySession kind attribute as 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 service 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 WAS, set the Container transaction type of the JMS router MDB to a value of NotSupported.
For Web service 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 option Allow JTA demarcation. This 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 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 AST, refer to the Application Server Toolkit information in the navigation pane of this infocenter.
- From the popup menu of the project, click Deploy to generate EJB deployment code.
- Optional: Test your completed module on a WebSphere Application Server installation. Right-click a module, click Run on Server, and follow the instructions in the displayed wizard.
Use Run On Server for unit testing only. The assembly tool controls the WebSphere Application Server installation and, when an application is published remotely, the assembly tool overwrites the server configuration file for that server. Do not use Run On Server on production servers.
What to do next
After assembling your application, use a systems management tool to deploy the EAR file onto the appserver that is to run the application. For example, use the console, as described in Deploying and administering J2EE applications.
Related tasks
Configure transaction properties for an appserver
Developing components to use transactionsAssembling applications
Related Reference
ActivitySession and transaction container policies in combination
Local transaction containment considerations
Transaction service settings
Related information
Enterprise JavaBeans specification WebSphere Application Server Development Best Practices for Performance and Scalability