Archives for : May 2018

Lets recall transaction processing (Java with Spring)

Generics about transactions

I am writing a piece about transactions because the subject of transactions sounds so heavy standalone and also because I recently had to recall all the theory from university about it. And surprise surprise, real life software behaves/looks different than in the theory. So, if you are looking to refresh your knowledge and also get the bullet points to simply solidify knowledge keep reading… (at least the bullet points).

Transaction processing is information processing in computer science that is divided into individual, indivisible operations called transactions. Each transaction must succeed or fail as a complete unit; it can never be only partially complete.”

“Transaction processing is designed to maintain a system’s Integrity in a known, consistent state, by ensuring that interdependent operations on the system are either all completed successfully or all canceled successfully.”  Wikipedia

Only reading the definition of transactions we are remembered of the correct way of using them and what the goal should be:

  • indivisible operations
  • succeed or fail as a complete unit
  • goal is to maintain a system’s integrity

We got that right on our agenda, lets turn to the technicalities of it. A good example which occurs most in real life software is the work with databases. Databases should have a build in mechanism to tap into their transactional usage either automatic – it takes care on its own on these or more “manual” – it is up to the developer to decide when the transaction starts and ends. Find out in the design and requirements phase which scenario you need and set the parameter of the database correct:

  • database auto-commit true or false

I want to focus on the database.autoCommit(false) scenario because we differentiate between actions and on some, transactions are not necessary.  Just because we have to also mention, a reliable transactional system must comply to the ACID criteria to be good (atomicity, consistency, isolation, and durability). When you use a transactional system you just need to know that you can depend on this expected behavior but you do not need to be concerned with each one of them in depth. However, the way you use transactions could violate one of the criteria and the result will not be because, for example, the database handles it wrong, but because you throw an Exception when in fact it should only be a warning. Conclusion is:

  • you can rely on the ACID criteria the transactional system complies to*

Spring Framework transaction abstraction

Lets get specific and take Spring as a framework that can help you take control of the database transactional system. Exactly how I mean it: Spring is not the actual transactional system but it exposes an interface, that perfectly integrates with different transactional systems and it is called Spring Framework Transaction abstraction.

To get started you need for both programmatic and declarative transactions in Spring to:

  • define the correct PlatformTransactionManager implementation (usually through dependency injection)
  • use the TransactionStatus interface to control transaction execution and query transaction status

The Spring transactional abstraction offers a lot of flexibility when it comes to controlling the transactional system. The implementation you choose must be a trade off between how tightly coupled you want/need to be to Spring’s transaction infrastructure and the need to use a non-invasive lightweight container which has less impact on application code. In this regard you need to choose between:

  • programmatic transaction management in Spring
  • declarative transaction management in Spring (XML or annotation based approach)

You can check out the differences in more detail in the Spring documentation. And a few words on how to chose between them is mentioned here.

Some general advice when using Spring transactions:

  • You are strongly encouraged to use the declarative approach to rollback if at all possible. Spring docu
  • When using proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do so no error is raised, but the annotated method does not exhibit the configured transactional settings. Spring docu
  • Spring recommends that you only annotate concrete classes (and methods of concrete classes). Spring docu
  • @Transactionaannotation on the method in the same class takes precedence over the transactional settings defined at the class level. Spring docu
* of course, unless you need to debug exactly that and find out an enterprise ready system has bugs – bad luck…

To be continued…