The ACID test is whether you satisfy the following conditions:
  • Atomicity - a change is all there or all not, you never see half of it there and half not arrived yet.
  • Consistency - if you have defined any constraints on valid data (eg any person_id must be in the person table) then no transaction will result it in being violated.
  • Isolation - each transaction has a consistent view of the database.
  • Durability - once a change is made, it will be protected against any failure mode that you can protect against.


Any decent relational database will provide these guarantees, and in many applications they matter a lot. Another piece of nomenclature, with transactions people eventually either commit the transaction (save it, let others see it) or rollback the transaction (undo what you did, pretend you never thought of doing this).

It goes on to explain the benefits of ACID. Which are many. And to point out that ACID is not all that you might want - there are stronger conditions. For instance transactions are serializable if any sequence of actions gives the same result as if the independent transactions were done in series. They mention that databases often offer different isolation levels, and you may not be serializable.

If you don't know about this, their explanation will confuse because you won't see how ACID and serialization are different. So I'll give an example - namely Oracle. By default Oracle always tells a transaction that the world looks like it did at the moment that the transaction started. This is ACID but is not serializable. Suppose that two transactions both start at the same time, and each will read a counter and increment it. Both fetch the original value. Both increment that by one. Both save the original value + 1. The counter is therefore incremented by 1. If the one transaction happened after the other, then it would have been incremented by because the second transaction would have seen what the first did. But that isn't what happened - by default Oracle is not serializable.

The article says that ACID is a good thing. Except that providing these guarantees for long-running operations creates operational problems. (I partially disagree with that. For user-facing operations they have a point. For batch processing it can be good even if the operation is very long-running.) They point out that no known transaction algorithm handles this well.

The two known classes of transaction algorithms are optimistic and pessimistic. Optimistic ones hope that there will be no conflict, do work, and then rollback the transaction if there is a problem. Which means that you might unexpectedly throw away a lot of work. Pessimistic ones fear that there will be conflict so they take locks early so that nobody will ruin your work. Now short-lived operations might be blocked indefinitely by a lock. Neither is very good.

They then turn to talking about solutions for long-running applications that don't give you ACID, but they do give reasonable properties and avoid operational problems.

The first is Sagas. In these you do short transactions at defined points. If the whole series of transactions do not complete, you then undo what you did. The example that they gave is that you reserve a hotel room at the first step (be sure that you'll be fine when you get there) and arrange to unreserve it if the person doesn't fill the form out in time.

They mention that Sagas are not well-supported in standards. But J2EE will support JSR 95, which offers tools to support whole classes of transaction models, of which Sagas are but one. (Of course that will be more complex to do in reality than using something that just supports Sagas.) They then explain how to use that to set up Sagas, and then explain how to use that in the toy reservation example that they had. Most of the details of which depend on how JSR 95 works, and so are useless unless you want to use that, or want to set up something equivalent.

Cheers,
Ben

PS I'd expect any competent programmer to be able to look beyond the fact that they were talking about Java to be able to get out most of what I said above. What I would excuse not getting is stuff like how a database can be ACID but not serializable - if you don't know that from experience then you are unlikely to think of it on your own. And that has more to do with how well you understand databases than Java.

PPS I am not a Java programmer.