--- Ron Jacobs <[EMAIL PROTECTED]> wrote: > >Compose in any order? Sounds like a good way to get deadlocks. > >I've found this, whilst a nice sounding idea, isn't very practical. > >But it could just be me. ;-) > > COM+ is designed to prevent deadlocks and has a long history of doing > just that. It makes building a transactional application simple as > building a single user app.
My apologies for my poor to non-existent explanation. :-( My point is that it is better, as a rule, if you avoid creating multiple COM+ objects from a root method. - The cost of the COM+ context for addition objects is not insignificant - You often need more lines of code to do create and call another object than to just write a bit of SQL code (although this is not as bad in .Net as it was in VB6 and to a lesser extent VC6). This assumes you have a wrapper class file around ADO/ADO.Net. - The amount of actual sharing of sub-objects is pretty low in the systems I have seen - The overall visibility of the entire transaction is hidden - i.e. is it harder to see at a glance which tables are accessed in which order. This makes writing deadlock free code harder. If typical methods in a COM+ were long then there would be more value to the technique. As it is, like I said originally, it isn't IMO very practical (as a rule). I don't understand your comment: How does COM+ help to prevent deadlocks over manual control of transactions? Many thanks, Peter __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
