Durability: From all the properties of the ACID acronym, durability is the simplest to understand.Some isolation violations are allowed in some cases and based on the business requirements. Meaning if a transaction is dealing with a given value in the DB and at the same time another transaction comes to deal with the same value, the second transaction should wait for the first transaction to finish its operations in order to proceed. One of the ways to achieve this is using locks or enforcing some isolation level strategies on the DB. Though different transactions can run concurrently, the Database operations should still be executed in a way that avoids concurrency issues. Isolation is all about concurrency of multiple transactions. Isolation: In transaction management, each transaction should be independent of other transactions happening at the same time.Another example is if a column should only contain numbers, we should never find some places where it is storing different formats like images or names. For example in a banking system, we should never allow the balance value to be negative. Consistency emphasizes on never allowing constraints violations. We need to ensure our data is always in the format we expect and we avoid having surprises. Consistency: in transaction management, we want to have values correctness maintained before and after the transaction.Commit: If a transaction commits, changes made are visible. We roll back the data to its previous state.

Abort: If a transaction aborts, changes made to the database are not visible. In the atomicity property there are two possible outcomes: We should not let the possibility of the debit operation being successful but the credit operation fail.Ītomicity is also known as the ‘All or nothing rule’. if even one operation fails, then all of them have to fail and the DB state is rolled back.Īnother example: in an application that transfers funds from one account to another, the atomicity property ensures that, if a debit is made successfully from one account, the corresponding credit is made to the other account. We should never find ourselves in a situation where we have created data in the api_credentials table while the creation of the user failed. What Atomicity means is that we should never allow a situation where we have inserted data in the balance table while the creation of balance_history failed and vice versa.

finally we create API credentials in the api_credentials.

Then we create some preferences in the preferences table.

After that we create an initial record in the balance_history table.

Then we create a balance for the user in the balances table.

We create the user data in the users table.

One example: considering we have application and in our service layer we have this sequence of operations during user registration: This means that either the entire sequence of operations succeeds or it all fails.

Atomicity: As mentioned above a transaction should be considered as a single unit of work.

I present my appreciation to all the engineering team at Reloadly and especially the Apollo Team that is doing an amazing job and making collaboration and communication look easy to maintain. I owe special thanks to Arun for being such an amazing mentor and leader and Emmanuel for the endless coaching sessions and investing in Reloadly’s engineers skills.

Creating a ground for other engineers to bring more ideas based on their experience and expertise.

Understanding how Reloadly makes use of Transaction management capabilities offered by Spring.Understanding the concept of transaction management.This paper is open to correction and modification from any internal engineer who finds flaws or sees an opportunity to improve its current content. This research paper has the aim to provide a deep understanding of transaction management in general but with reference to Reloadly microservices. Detailed explanation of ACID properties.

Spring boot transaction management