>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 have read Tim Ewald's book and agree with the idea of 'processor' objects. (Had a good conversation with Joe Long on the newsgroups - see 'OLE/DB and Transactions' in microsoft.public.platformsdk.complus_mts on 22 March - 16 April ) However, as systems get more and more complex, this is not always possible, and a 'business tier' component may have to call several other 'business components' (each of which call several 'data tier' components) as well as several 'data tier' components to complete its task. >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. I am trying to design the system to use 'one method per transaction' as much as possible, but I don't think this will be the case 100% of the time. Also, the system I am designing has two sides to it. It has the run-time side, which will have one method per transaction to achieve scalability. It also has a 'design time' side to it which has a good object hierarchy and uses transactions to controll complex state. IE The 'developer' will have created many inter-related objects in memory before deciding to save them. The transaction then controlls whether they all get saved, or none of them. Speed and scalability are not issues here, but multiple objects working together to get an atomic task done is. I should have stated this in my first post - apologies - and this is the area that I am asking for. >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. Thanks for the idea. I am researching into them. >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. And probably going to be amended or removed without notice! >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. :) Restating: I should have explained earlier that this was not for scalability's sake, but for the design time use of transactions to maintain state. Thanks for your help, and if you have any further ideas now that I have (hopefully) explained my reasons, I would much appreciate it. 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.
