Between PDC and now, I was in Redmond on Monday and Tuesday at a meeting with the Indigo team. One of the topics discussed were the new transaction management capabilities that are part of Indigo (which, for Longhorn, includes a lightweight transaction manager).

Ingo was there, too, and we had a little argument about how hard it is to write transaction resource managers. Ingo thought that it would be awfully hard to write them and that average programmers would never do so and wouldn’t see the need for them. I said “hey, it’s really trivial”, explained that I consider transactions a very general programming paradigm for much more than just databases and told him that I would write a little demo to prove it. I wrote the demo on the plane going home in about 3 hours. Here it is.

The “2 Phase Commit Puzzle” application is a little Windows Forms puzzle that doesn’t use Indigo or the Longhorn bits, but rather employs a little lightweight 2PC transaction manager that Steve Swartz and myself hacked up when we were on our Scalable Applications tour this spring.

The puzzle uses four resource managers (transaction participants). The TileWorker keeps track of the tiles as they are moved around, always votes “yes” on Prepare, does nothing on Commit and rolls all tiles back into their original (shuffled) state on Abort. The TimeoutWorker votes “yes” if the puzzle is completed (pressing the “Done” button) within the preset time-span and “no” otherwise. It does nothing on either Commit or Abort otherwise. The GridWorker votes “yes” on Prepare if the puzzle is completed (order is correct) and otherwise “no”. It also does nothing on Commit or Abort. The OutcomeContingentMessage is a participant that will always vote “yes” on Prepare and shows a “Congratulations” message on Commit and a “You failed!” message on Abort.

The great thing about this little puzzle is that I could add arbitrary other success/failure conditions for the outcome of the puzzle (e.g. number of moves) without having to rewrite or even touch the code determining the other conditions or the code emitting the result message. I would just have to hook in the new resource and feed it with information from the grid.

Transactions aren’t just for databases. The discussion of the theory behind this is of course in our already well-known transaction deck.

Below are the download links to the game executable (in IE, you need to right-click and save it to the local disk; it will not work if started directly from IE) and the source code archive, including the simple WorkSet transaction manager. Check it out.