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). 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). 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)? 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. Regards, Mark Plummer You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
