Someone Needs to be Shot

So, I am working with some ServicedComponents so that I can use COM+ transactions. For some reason, every time my method returns, all my fields are null. It doesn't make sense to me, so I step through the program to see what is going on. The set methods are called sure enough and the properties are indeed being set properly. So, I do a google search and find in a newsgroup posting from MS developer support that this is the "Expected behavior" for any ServicedComponent which has a method marked as AutoComplete. As soon as the method returns, the object will be destroyed. So, if you have any fields, they will be reset. Now, I have two questions: who is the moron on the .NET team that thought that was a good idea? Has he been fired yet?

Why the hell would I want to use objects that randomly lose their state?

6 Comments

  • This is, in fact, expected behavior for any auto-complete transactional component in COM+. I'd recommend you read "Transactional COM+" by Tim Ewald...

  • Yes, but it is stupid behavior. COM+ 1.5 with .NET should be able to handle this by now with the support for entering and leaving the transaction context at will.

  • So, is there a way to "break the programming model" so to speak and keep state? You can't seriously say that only stateless systems are scalable...that's a load of crock if I ever heard one. I could see that being an issue if you were using remote objects, but these objects are not remoted, they are running on the same server, so there is no real reason they should HAVE to lose their state.

  • To echo the first comment, I highly recommend that you start by reading "Transactional COM+" by Tim Ewald. This will go a long way towards explaining how state and transactions are modeled in COM+ and most importantly, why they are modeled that way.

  • Sorry Jesse, but Chad is correct. As a former CICS (and current COM+) programmer, I wouldn't have it any other way.





    Think of it this way. You wrote the Serviced Component, so you should control all aspects of it, especially when your component is destroyed. Back under VS6, if the client calling your component controlled your components destiny, so if the developer forgot to destroy the reference to your component, it would be left hanging out there, and you as the component developer had no control over that. This way the power is in your hands, and not some developed that doesn't totally understand what is going on in your component.





    Don XML

  • Yeah, welcome to the world of stateless programming. MTS/COM+ have behaved like this for a while now.





    If they didn't destroy their state, there really wouldn't have a good way of making sure that whatever objects that were still in memory were truly done doing what they were working on (ie, open connections with half a transaction completed). So, kill it all off.





    I'll echo the Transaction COM+ book, and maybe the Effective COM+/MTS Visual Basic 6 book.from A/W.

Comments have been disabled for this content.