The Programmatic Transaction Model
In this transaction model, unlike local transaction model, developers actually manage the transactions and are completely isolated from the underlying database connections. In this model the developer is responsible for managing the transactions programmatically.
In this model it’s the developer’s responsibility to obtain transaction from the transaction manager, start the transaction and commit the transaction. If an exception occurs it’s again the developer’s responsibility to roll back the transaction to its previous state. It results in a lot of error-prone code that tends to get in the way of the business logic in your applications and can be maintainability havoc. However, some applications force the developers to use this model due to various considerations.
Spring’s way of doing programmatic transaction model will be explained in detail in the later sections of this chapter.
The Declarative Transaction Model
This is the most common transaction model in the Java Platform. In this model, the container environment in which your application is hosted manages transaction completely like starting, committing and rolling back operations. The developer is only required to specify the transaction behavior and the container takes care of it in all aspects.
Spring’s way of doing declarative transaction model will be explained in detail in the later sections of this same chapter.
The various transactions requirements in your applications are not addressed by these transaction models but they aid in developing your applications transaction strategies. In the following section, we will see some of the well know transaction strategies which can be adopted in your application as is, but these are only some of them and are not exhaustive in any way. You can get more details from a well written article written by Mark Richards, Director and Sr. Technical Architect, Collaborative Consulting, (http://www.ibm.com/developerworks/java/library/j-ts2/index.html). The article is written sometime back but the basics for these are relevant in all aspects now as well.
As discussed earlier, transaction model describes how transaction behaves and how they are implemented in the Java Platform, but how they can be used in your application is decided by the various transaction strategies. The transaction strategies as discussed by Mark Richards which can be adopted as is in your application are as follows (it discusses these strategies in very nascent form as it is difficult to cover it in this book extensively):
- Client Orchestration transaction strategy – In this strategy, the client can decide to call multiple server-based or model-based method calls to fulfill a unit of work, which we call as a transaction. The client layer owns the processing flow and “steps” needed to complete a particular request. In this, the transactional unit of work must reside in the client layer to ensure an atomic unit of work.
- API Layer transaction strategy – If your application has coarse-grained methods (service methods) which act as the primary entry point to your application, you are using this transaction strategy. In this a client calls a single call to the back-end to perform a unit of work. This single method call has the responsibility to do the necessary orchestration to perform the appropriate insert, update and delete operations to establish a unit of work.
- High Concurrency transaction strategy – This is a variation of API layer transaction strategy. The main idea behind this transaction strategy is to shorten the transaction scope so that you minimize the locking of various resources like database while still maintaining an atomic unit of work for any given client request. This strategy is used primarily in applications that support a high degree of concurrency from a user perspective.
- High-Speed Processing transaction strategy – This strategy is used when you need to get the absolute fastest possible processing time from your application and still maintain some degree of transactional atomicity in your processing. t is perhaps the most difficult and cumbersome transaction strategy to implement out of the four.
For more details, you can read a wonderful book on this topic titled “Java Transaction Design Strategies”, written by Mark Richards.
Before going into transaction management details, I would like to introduce the various transaction states. They are:
- Active – This is the initial state of transaction. The transaction stays in this state while executing.
- Partially Committed – This is the state of the transaction after the final statement has been executed.
- Failed – This is the state when it is determined that normal execution can no longer proceed for this transaction.
- Aborted – This is the state of the transaction when it has been roll-backed and the database taken back to its initial state before the start of this transaction.
- Committed – The state of the transaction after successful completion.
Figure 9-1 describes transaction states pictorially.
Figure 9-1. Transaction States
Page Visitors: 8819