Transaction strategy based on the Java transaction model

Transactions are essential to ensure data integrity and consistency. To fully understand a business, you have to be familiar with some basic concepts, models, and strategies. Mark Richards said "confusing the transaction model with the transaction policy is a common error". This article addresses the three transaction models supported by the Java™ platform and discusses the four main transaction strategies based on these models. By using some examples of the spring framework and Enterprise JavaBeans (EJB) 3.0, Mark describes how the transaction model works and why they can be used as a cornerstone of transaction processing from basic to high-speed transaction systems.

The Java platform supports three transaction models:

* Local transaction model-transactions are managed by a DB resource rather than an application container or framework. Developers manage connections rather than transactions.

* Programmatic Transaction Model--developers get transactions from the transaction manager, and then need to write their own transaction initiation, commit, exception, and rollback code.

* Declarative Transaction model-the most common model, also known as container management transactions. In this model, the container manages the transaction, and the developer defines (declares) the behavior and parameters of the transaction.

However, this support can only describe the basic information and expected behavior of the transaction and the syntax and rules used. Transaction policies address the question of when to use required or mandatory attributes, specific directives, which models to use, and how to optimize specific situations.

In a previous article, Mark discussed the advantages and pitfalls of the transaction model.

This article describes strategies for using a specific model and how to use the model in a proper manner. These four policies are listed below:

* A client-Orchestration transaction strategy is required when multiple server-based or model-based calls are made by the client to complete a separate unit of work.

* Use the API Layer transaction strategy when the primary entry method for the backend invocation is coarse-grained (if you want to call it a service).

* High concurrency Transaction policy is a variant of the above strategy that needs to be used when applications cannot support long transactions

(typically based on performance and scalability considerations).

* High-Speed transaction strategy is perhaps the most extreme of a transaction strategy. This policy can be used if the application requires the fastest processing time (and throughput) while maintaining a certain transaction atomicity during the process.