Helping ordinary people create extraordinary websites!
| |
Helping ordinary people create extraordinary websites! |
Understanding JCA TransactionsBy Mikhail Genkin2005-04-22 
Transaction Demarcation Strategies
The JCA gives you two options for handling transactions: programmatic transaction demarcation or declarative transaction demarcation. The first option requires that you use the Java Transaction API (JTA) to write explicit code for each transaction's begin, commit, and rollback operations. In this case, your transaction demarcation code is intermixed with code that implements the business logic. The second approach, declarative transaction demarcation, does not involve any extra coding. If I choose this approach, the EJB deployer will configure the transactional behavior for me by modifying deployment descriptor settings for the beans. The EJB container will then use these deployment descriptor settings to automatically begin, commit, or rollback transactions at specified points. In this case the business logic implemented in the EJB component remains portable and the transactional behavior can be adjusted without re-writing the bean implementation. For most cases declarative transaction demarcation is the preferred option. Programmatic demarcation is typically used only in cases where declarative transaction demarcation isn't flexible enough. In the case of my example, the two EISs and their corresponding resource adapters have different transaction support levels. Were these the only factors under consideration, a distributed transaction using the 2PC protocol would be the best approach to guarantee data consistency and integrity. Making things more interesting, however, is the fact that in my example only EIS2 supports distributed transactions. In order to use 2PC, all systems involved in the transaction have to support it. Therefore, I cannot use a distributed transaction, and will have to rely on local transactions in order to guarantee consistent updates across the two systems. I will need to group access to each EIS, and manually undo changes to one EIS if the other one fails. Transactions that undo previously committed changes are frequently called compensating transactions. I'll use programmatic transaction demarcation to provide for greater flexibility for manual updates. 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
|
 |