A number of developers frequently talk about the fancy term, transaction management. How many of us find ourselves comfortable working with it or its customization? Is it really so difficult to understand? Does adding a transaction to the code need to add lots of complex code? No! Actually, it's the easiest thing to understand as well as to develop. The transaction management is very much common while discussing, designing, and developing a persistence layer that deals with the handling of data to and from the database. The transaction is a unit of sequential multiple database operations where either all the operations in it are executed successfully or none of them are. Transaction management is the technique that handles a transaction by managing its parameters. The transaction maintains the consistency of the database, depending upon the given transaction parameters, so that the transactional unit will either be a success or a failure. The transaction can never ever be partially successful or failed.

Now, you may be thinking what's the big deal if any one of them fails? Moreover, why was it so important? Let's take a real-time scenario to understand transactions. We want to open an account on one of the websites for online shopping. We will need to fill the form by giving some personal information, and we will need to select a username, using which we will do our online shopping. The information will be collected by the application and then saved in two tables; one for the users, that have username as the primary key, and the second for user_info, where a user's personal information will be stored. After the collection of data from a user, the developers will perform an insertion operation for user's information in user_info, followed by inserting the data in the users table. Now, consider a scenario where the data collected from a user gets inserted in the user_info table successfully; however, unfortunately, the username already existed in the table, so the second operation failed. The database is in an inconsistent state. Logically, the data should be either added in both the tables or in none of them. However, in our case, the data got inserted in one table, but not in the second. This happened because, without checking whether the row got inserted or not, we performed the insertion operation permanently, which now cannot be undone, even upon the failure of the second operation. The transaction management helps the developers maintain the consistency and integrity of the database by either making all the operations reflected correctly in the database tables or none of them. If any operation in the unit fails, all the changes made before that will be canceled. The following figure gives us a clear understanding of all that we just discussed:

Of course, it won't happen automatically, but the developers need to play a key role in that. In JDBC, instead of going with autocommitting the operations, developers choose to go with committing the transaction or rollback if any operation within it fails. These two are very important terms when it comes to transaction management. The commit reflects the changes in the database permanently. The rollback undoes all the changes made by all the previous operations before the failure happens, making the database go back to its original state.

The following are the ACID properties that, in the 1970's, Jim Gray defined to describe a transaction. The properties are later on known as ACID properties. Gray also describes the ways to achieve ACID properties. Let's discuss them one by one.