• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 712
  • Last Modified:

Why stateless components in COM+???

Hi. I keep reading in a lot fo sites that you cannot maintain info state on a component running in COM+. However, given that VB threading model doesn't allow COM+ to pool it's objects, I see no sense in having stateless components... Anyone can bring me a light on this?? I'm not doing stateless components unless it's really needed!!
1 Solution

That is a common misconception. State can be maintained in a COM+ object within a transaction. So if you start a transaction in one method, then finish it in another, you can have state between those two methods and any methods called between them. As for the technical details about how you do this, I have never tried myself.

Well, you're both ignoring one of the main reasons that you would want to use COM+ in the first place, and that is scaleablity.

Let's say that you have 1000 users trying to use the component at the same time.  With Advanced Server and Site Server(?) it's easy to set up clusters of servers that can be load balanced.  But if you're busy maintaining state in a component, then that means you have to maintain the connection to a particular instance of the component running on a particular box.

If you design your components to be stateless, then each trip to the component can be redirected to the most available box.

Also, I've seen a number of people post questions here about transactions they have used to try to span multiple method calls not being rolled back properly.  While it might be theoretically possible, I don't think that it is as reliable as a stateless model where each call is a separate transaction.

I've used the stateless model on two large international enterprise applications with great success and reliability.

Here is a section of a white paper from Microsoft on COM+ application development guidelines that we followed pretty closely:


(download the complusprint2.exe self extracting zipped document)

Adopt a Stateless Programming Model on the Server
This design issue has been debated thoroughly in many channels and has been approached in different ways. Although there are many reasons to go for stateless designs, stateful design has its niche. However, correct software distribution methodologies suggest that for OLTP server operations (a shared resource/concurrent isolated activity environment) the stateless approach is optimal in most cases. They allow for an interdependent, easily cloned, design of services with transparent failover, easier load balancing, less resource contention, and easier management of transactional data.
In addition, a stateless approach is more linear in design and implementation than a stateful approach. This means that it reduces dependency on time-variant factors or method call sequencing, producing activities that are more isolated and providing a finer granularity for load balancing. It is easier to develop software from a single-user activity standpoint than it would be to deal with all the issues involved in state management.
More Information
Exceptional reasons to maintain a user/session/instance-specific state in a server object is when all of the below hold to a strong degree:
7      The data being kept is expensive or impossible to reacquire.
7      It has undergone a transformation that is too costly or impossible to perform on the client machine.
7      It has undergone a transformation that is too costly or impossible to redo on the client machine.
7      It is too expensive or impossible to transmit the state data to the client.
7      The data is not duplicated in an alternate transactional store.
If most of the above holds true, you have a strong candidate for a stateful server-side programming model. This might improve your performance but it will drastically reduce your concurrency and maybe your scalability.
At this point, you must ask yourself if this piece of data belongs in an OLTP-ish TP environment. You may evaluate alternate state management methods (storing to specialized databases) or transport mechanisms. Also, evaluate the benefits of asynchronous operations when dealing with this type of information.
How To
Make sure you have good state management approach in your server:
7      You do not have global variables that cache information in Recordsets, Collections, or Dictionaries. These will cause bottlenecks and failures.
7      Your classes have no class-level members (Private or Public variables) that have a lifetime beyond that of one method call. Use parameters on the functions instead of properties (network roundtrips are more expensive and network packets seldom have to be wasted because of larger numbers of parameters). In general, the only Private variables you will have are those initialized from constructor strings.
7      Your methods open connections to resources and close them immediately. All ADO objects that have been opened are closed, and all objects created are explicitly released by setting them to nothing.
7      You call ObjectContext.SetComplete/SetAbort before returning from the method.
Microsoft Systems Journal (MSJ): Q&A ActiveX/COM by Don Box (http://msdn.microsoft.com/library/periodic/period98/activex0398.htm)
CuervoAuthor Commented:
Ok, that's something to follow

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now