Clemens Vasters posts a puzzle (literally): Lightweight Transactions. He’s advocating using transactions for general error handling and state management. His presentation about transactions calls this style of coding Prepare/Commit/Abort, and the more traditional style Do/Fix. (Actually, he first calls the new style Consider/Confirm/Perform, but I still don’t understand how those names map on to the concepts: there’s no Abort.)

Do/Fix is when you can ask a class to do work (Do), and then you can ask the class to undo the work if needed during exception handling (Fix). The problem with this is when you have a number of classes Do’ing things in a row: how do you know how to properly Fix across all of them? Prepare/Commit/Abort is when you can ask a class to consider a chunk of work (Prepare), then either do the work (Commit) or not do the work (Abort). These ideas will be familiar to anyone who has done transactional database work, but the point is that this style is applicable to many more domains. Just because databases first took problems seriously enough to apply transactions to them doesn’t mean that only databases should.

The puzzle he posts is a sliding block puzzle program where the different pieces of logic are implemented as separate transactional resource managers, interacting through a transaction manager to decide, for example, whether the puzzle is completed. This may be a contrived example. It’s interesting as a demonstration of using transaction for very undatabase-like work, but I don’t see that we’ve improved the lot of sliding-puzzle-writers by organizing it this way.

But he makes some good points in the presentation (it can be hard to follow since it is mostly diagrams, but you get the gist. Just skip any acronyms you don’t understand, they seem to be about Longhorn.) I can see the power in the transactional style. I’ve never built software this way, so I don’t know how it would feel in a real-world situation. I note that Joel’s challenge to me about exception handling would be handled more naturally with this sort of transactional model.