Helping ordinary people create extraordinary websites!
| |
Helping ordinary people create extraordinary websites! |
Understanding JCA TransactionsBy Mikhail Genkin2005-04-22 
EJB Deployment Descriptor Settings
In an EJB-based solution, the EJB deployer must tell the application server how transaction demarcation will be handled by configuring EJB deployment descriptor settings. The first step in choosing the correct deployment descriptor setting for your application is to asses its requirements. Here's what you know about the example JCA implementation: 1. The deployment descriptor for the CustomerSession EJB component has to indicate that you're using programmatic (that is, bean-managed) transaction demarcation (TX_BEAN_MANAGED). 2. Deployment descriptors for OrderService and CatalogService session beans should use declarative (that is, container-managed demarcation) and methods on these beans should always be executed in the context of a transaction. 3. The OrderService and CatalogService session beans provide access to underlying EIS transactions. Methods on these beans are called by the CustomerSession session bean, which implements the process logic behind your application, as well as by other process-oriented components. 4. The CustomerSession bean should start a transaction prior to calling methods on OrderService because the transaction will encompass multiple operations on EIS1. Because each of the two EIS2 operations can execute as independent transactions (and neither can be part of a global transaction encompassing all four operations), either programmatic or declarative demarcation could be used for the calls to CatalogService methods. (Note that I've already opted to let the CustomerSession bean control the transaction boundaries for all the operations.) Given these requirements, you could use the TX_REQUIRED deployment descriptor setting for CatalogService and OrderService beans. This setting would ensure that bean methods could join a transaction already in progress or start a new transaction if need be. Note that with TX_REQUIRED, if the calling code does not start the transaction, then each call, including those to EIS1, will take place as separate transactions -- which is not what you want. A alternative approach would be to force any component (for example, the CustomerSession bean) that implements process logic to perform transaction demarcation. This approach, which could be accomplished using TX_MANDATORY deployment descriptor setting for the OrderService and the CatalogService session beans, would ensure the desired transactional behavior for the application. If you chose this approach, the calling component would need to start a transaction prior to calling methods on the EIS facade, or an exception would be raised. One disadvantage of this approach is that it requires components that need only single-method transactions to be responsible for controlling transaction boundaries. Specifying the transaction isolation level The J2EE specification defines a deployment descriptor attribute that specifies the transaction isolation level for a given EJB method. For example, the EJB deployer could configure the transaction isolation level for the getItemPrice() method of the CatalogService session bean to execute with the TRANSACTION_READ_COMMITTED isolation level to ensure that only committed pricing data are read in during the transaction. By changing the isolation level, the J2EE developer or deployer can balance data integrity against performance constraints to performance tune the application. However, different EISs differ in their transactional capabilities and will react to transaction isolation settings in different ways. In this case, changing transaction isolation settings for EIS facades will make little difference, as the ECI and XCF communication protocols will not communicate this information to the back ends. COBOL transactions running on these systems will address transactional isolation aspects using programmatic techniques specific to those platforms. Choosing a solution In general, to determine how a given target EIS will respond to transaction isolation settings you will need to consult documentation for that EIS, and for the resource adapter that is used to provide connectivity. Although resource adapters used in the example do not respond to changes in J2EE transactional isolation level settings, some EISs built around relational database systems may be affected. It is important to understand the exact behavior that will result due to these changes in a particular EIS, as this can have significant impact on performance characteristics of the EIS and your application. In a worst-case scenario, the integrity of the underlying data could be compromised. Developers working on J2EE projects should consult with EIS administrators to ensure that correct policies for transactional isolation are being followed. Tutorial Pages: » Learn How the Various Levels of Transaction Support Provided by Different EISs and Resource Adapters Can Affect Application Design. » Overview of JCA Transactions » Transaction Support Levels » JCA Transaction Support » Transaction Demarcation Strategies » Programmatic Transaction Demarcation » EJB Deployment Descriptor Settings » In Conclusion » Resources First published by IBM DeveloperWorks
|
 |