Essentially, transaction processing is a model for various transactions, including both financial transactions and other processes like verifications. Experts contrast transaction processing with a different type of model called batch processing, where a larger number of individual transactions are handled collectively. Both can both be applied to standard e-commerce systems that handle financial transactions.
When we talk about transaction processing, the term "transaction" refers to the entire process. In order to be successful, the process has to be completed from start to finish. The money has to come out of one account and go into another account. With other kinds of non-financial transactions, different parts of a software architecture need to be updated. Otherwise the system may have what is called a "dropped transaction," (or what Microsoft calls "losing integrity").
The opposite of a dropped transaction is what's called a "durable transaction." These durable transactions are the fundamental basis for many online activities, such as ticket or event booking, credit card processing, and other quid pro quo arrangements were multiple systems need to be updated, and one digital event has to align with another. So how does transaction processing help ensure this sort of durability? Let's take a look.
ACID and BASE Transaction ModelsOver time, data specialists have produced various models that promote successful and durable transactions. One of these is called atomicity, consistency, isolation and durability, or ACID. This "hard" system of verifying transactions led to another model called basically available, soft state, eventual consistency, or BASE, a more versatile alternative. Both of these models can guide IT professionals toward more consistent transaction processing systems. For a simple idea of the way these two methods work, imagine two of those old analog marquee systems in a train station, where updates involve various shuffling pieces with timetable information. One of them clacks furiously for a few seconds, then quits. The other keeps going, winding down over time from a few tapering plunks and thunks all the way to eventual silence. The first example refers to ACID, while the second represents BASE. In both cases, the goal is the same: total data resolution. (For some background reading on ACID, check out our Introduction to Databases.)
Transaction ManagersAnother basic element of transaction process systems is the transaction manager. This term is one of the many personification-based terms in modern IT. It wasn’t too long ago that the term referred to an individual who was tasked with completing transactions, usually financial ones. In those days, a bank teller might have been called a transaction manager. By contrast, the term as it’s used today largely refers to an intangible element of the transaction processing system as a whole, but one with a predefined role.
The use of transaction managers, while enabling various kinds of TPS, can be problematic. For instance, developers who are working with J2EE or similar resources can find themselves at a loss when a call to the transaction manager returns various errors. All kinds of declarations and variables have to be right in order to call the transaction manager effectively, and developer forums abound with stories of these kinds of setups that just weren’t quite right.
Language-specific best practices guides (like this one for J2EE) can provide some tips on transaction management and other support methods like application development frameworks. Other transaction resources include the Object Transaction Service (OTS), which was produced by the Object Management Group to deal with certain complexities and cross-platform processes.
Microsoft has also come up with some broader resources; newer Windows OS versions ship with Kernel Transaction Manager (KTM), which can support C++ applications. Microsoft has also offered Microsoft Distributed Transaction Coordinator (DTC) since 2000 for cross-platform transaction support.
Other Considerations with Transaction Process SystemsIn general, there are a variety of key goals that have to be met for effective TPS setups. Data needs to be accessible in well-functioning data structures, and it needs to be protected from various kinds of failure. Sophisticated backup systems help to provide safeguards against cyber-attacks, natural disasters or other kinds of liabilities. Some of the tools mentioned above were created to help deal with data corruption and other problems that could have an effect on transaction durability.
Durable transactions mean that cross-platform updates also have to resolve. The ACID and BASE models are instructive here. A lot of the work that modern professionals do is related to this kind of consistency, and to making sure that one part of a data system matches another, all in order to support those key processes that are generally labeled a transactions.
Obviously, there are a lot more detailed elements of TPS systems and case-by-case problems and solutions to look at, but where a diverse group of people might be involved in addressing them (for instance, when a business has certain issues with its tech vendors), it makes sense to help clarify this key IT terminology first.