Recently, I have been involved in a number of discussions on Transactions, Transaction management, the different approaches to how Transactions can be performed, as well as the different types of Transactions.

It a very interesting area, as it is a part of computer science that has become such an integral part of Software development today. Sometimes when we think of Transactions, we think about ACID Transactions or perhaps associate Transactions as being a software development tool/pattern/service that only applies to Databases. While both are somewhat correct, they don't really explore the feature richness of Transactions or how they can be applied to so many scenarios outside of those that involve the transformation of state where databases are involved.

When I think of Transactions, I like to think of them as being a collection of patterns, interfaces and contracts that help us ensure the correctness of data/state, as we transform from one known state to another. For me, it is this collection of patterns, interfaces and contracts that make up the transaction paradigm and help us as developers and architects tackle one of the most difficult areas in software development, i.e. Concurrency management and Recovery control.

The reason that I like to think of Transactions this way, is I disagree with some of the commonly held views on Transactions have developed over time.

Some of these include:

- Transactions only apply to databases

- The many variances of the definition of the ACID properties, especially that of "D". (I'll expand on this in a later post)

- how the "commit" or "rollback" aspects of the paradigm can be sometimes viewed. Does the "Rollback" always have to be the inverse of every action that makes up the unit of work?

- Volatile Transactions can be seen as not being transactional. Same train of thought as that on some of the definitions of the ACID properties of Transactions that exist. (I'll expand on this in a later post)

Just me thinking out loud really... but I welcome any comments!