Today we are going to talk about distributed transactions, a common component of enterprise systems. First some definitions. Looking through past EXTOL blogs, the term transaction is used in many different ways. You might have specific meanings for the word in your own business. The kinds of transactions I’m talking about here are those at the software component level. These transactions may or may not mirror a higher level business transaction. There are many locations inside a software system where data is exchanged between components, but we usually don’t describe them all with the word ‘transaction’. The term is usually reserved for an exchange were certain conditions are maintained. These extra conditions are nearly always the principles of ACID [A]tomicity, [C]onsistency, [I]solation, and [D]urability. You can look up the details on Wikipidia, but in short, these ideas are important to keep ‘bad’ things from happening as the exchange is performed (such as interference from other actions executing in the system, unexpected crashes, etc…). Continue reading
On Friday we discussed redundancy as a universal attribute of highly available (HA) components. See “’High Availability’ 101 – Redundancy.” This time we’ll explore data replication, an application of redundancy that is common in many HA systems.
Often, the first hurdle in creating an HA component involves accessing data in a highly available fashion. Unfortunately, it is also one of the most complicated and expensive problems to solve. Applying the principle of redundancy introduced on Friday, highly available data means redundant data. Redundant data requires the act of copying it to redundant locations. This copying is sometimes referred to as ‘replication’. Highly available data requires some form of replication. Complications may result from the potential overhead of this operation, and maintaining consistency between the disparate copies. Consistency is especially troublesome if the data is capable of being read and modified concurrently. Continue reading
High Availability (HA) is just one of those topics. Ask five people to define HA, and you’ll probably receive five different answers. I’m not immune to this myself, but I’d like to explore two universal attributes I believe all highly available systems share. The topics will be split across two blogs. This time we’ll talk about redundancy, and in the next installment, replication.
Availability is the probability a system can fulfill its function on behalf of the user (be it human or another component) at any given point in time. For example, if your system is 90% available, the user should expect to receive service nine times out of ten. The quantification of ‘high’ in ‘high availability’ is arbitrary depending on the context, but we are usually talking high 90s, and even counting the number of trailing decimal 9s on 99% for certain applications. Continue reading