Pay Attention to the Details

Oh, man! It has been a long time. I have been busy with so many things -- the most important is to watch Daniel grow and adapt to that. He is close to crawling now. He speaks his own language by now. Unfortunately, I guess you have to be his age to understand.

Anyway, I recently dug out some of my transaction WCF code. In the analogy of the dust that needs to be brushed off a book you have not read in for a while, I had to first of all find the sample -- one or two paves have come in between now and the last time I touched the code. Other than that, I didn't exactly recall the code in the state I found it. But, of course, my ample comments easily allowed me to see what modifications I made -- because, we all comment our code. Especially when you reach my level of forgetfullness.

Anyway, I could for the life of me not figure out why all my transactions aborted. Unfortunately, I did not find much help in the exceptions that got thrown. What was the clue was an extra parameter I gave one of my methods. Remember, this was done purely for demo purposes. The parameter was describingly called shouldAbort and of type bool. This was of course set to true.

Now, that I knew what the problem was, it made me realize what I had intended back then: I want you to make a concious decision if your method should vote to commit or abort the transaction it may participate in. I really, really don't like that someone or something tries to make a guess on my behalf. Setting the shouldAbort to true would skip the call to OperationContext.Current.SetTransactionComplete(). No wonder things were aborting for me.

So, I guess my point is this: Be explicit about the vote on the outcome of the transaction. I know that there is a reason that you can mark your methods as voting to complete if no exceptions cross boundaries etc, but I am not fully understanding the idea behind it. It may come one of these days now that I am again working on this. Until then, I guess I will pay more attention to the details.