I don't think I would call EnableCommit as a matter of course (for example, as the first line of code in PlaceHolder). What that says is, "Regardless of what I do with the code in PlaceHolder that may impact my transaction, I choose to vote for committing it anyway." That is to say, in general, you call EnableCommit *after* the body of your transaction-aware code has executed, to tell other participants in the transaction that your code is unaware of any reason not to commit. Second (and I am not a COM+ transaction authority), my understanding of AutoComplete versus EnableCommit is that AutoComplete is used to both ensure the creation of a transaction, and ensure that SetComplete is called if the tagged method returns normally(PlaceHolder in this case). Marking the method as AutoComplete(true) suggests that PlaceHolder is the first and last bit of logic to use the created transaction. Can't tell by your question, but I must assume there may be other methods called either before or after PlaceHolder that also intend to use the transaction. SetComplete sets both the IsConsistent and IsDone bits on a transaction context, indicating that the transaction should proceed with the act of committing itself (bad news if other logic needs the transaction), while EnableCommit only sets the IsConsistent bit, allowing further code to use the transaction instead of trying to commit it immediately. If PlaceHolder actually sits in the middle of other methods, all of which are intended for use in the same transaction context, setting EnableCommit at the end of PlaceHolder's execution would be the right choice with regards to transaction integrity.
The most exciting phrase to hear in science, the one that heralds the most discoveries, is not 'Eureka!' ('I found it!') but 'That's funny...’
