> I am designing an n-tier system that (for the forseeable > future) will only ever write to one database. > > I have previously used C++ and COM+ to manually enlist pooled > objects into the current transaction (if there is one) for > distributed transactions using OLE DB. (Using ITransactionJoin).
First of all, have you read Tim Ewald's book, "Transactional COM+"? If not, stop, do not go further until you have. It will change the way you do things. For one thing, Tim explains why having two objects participate on the same transaction is inherently antithetical to scalability. :) > I know that in .NET (SqlClient and OleDbClient) you can pass > around the connection and transaction object to enlist on, > but that would put me back to square one. (IE It is fine to > do in simple cases, but when your object hierarchy becomes > complex, the amount of permutations will over-complicate the > code. Also, I would like to write a framework on which the > more junior programmers can easily work). Assuming you don't elect to go to a simpler design where transactions don't span methods (which is my recommendation), a couple of things come to mind here. 1) Store the txn in a static field of some class. Simple, direct, easy to do. But it won't span AppDomains. 2) Make use of CLR Call Context. See CallContext and ILogicalThreadAffinitive in the docs. > Is there an efficient way to create a Attribute Class that > will store iteself in the Object Conext Object (Either by > using EnterpriseServices or doing it manually) and that can > keep hold of the transaction object of its creater (if its > creator was also attributed with this Attribute Class)? Not exactly. There is something called Context Attributes. It appeared in earlier CLR betas, and can be used to do what you want, but Microsoft "undocumented" it, meaning it's right up there with Channel Hooks as an unsupported technology. > This way it would be the same as declarative transactions (IE > ease of use - Aspect Orientated Programming) without the > overhead of the 2-phase commit, which would not be necessary. > > Any help would be greatly appreciated. Restating: read Tim's book. Then redesign your system, because you'll want to. This problem will totally go away, and your system will scale better. :) You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
