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

slight confused...about com+ services

I am slight confused. Its about com+ services..

lets say i  am using objectcontext in my VB code(ActiveX dll) i have implemented transaction through code successfully....but now what i have to do is to register my component as a COM+ service component(for transactions to work...am i right??) finally i have my DLL as a registred Com+ comp. In component servies (windows 200) when i check the transactions tab of my com+ comp., it is showing transaction support as disable, Not supported, Supported, Required,Requires New. what does this means...it it going to override my component transaction support which i have coded...or why do i need to code objectcontext if i can do it from this tab...and this tab has the same properties as that when you look in class properties of ActiveX Dll i.e. MTSTransactionMode...why this repetition, what does this mean..

a clear answer is appreciated.....ca you give me some documentation on this which clearly explains this....

1 Solution

It is a little confusing, and it's been a few years since I've worked with it, so, you'd best read through the documentation yourself for the best understanding of how it all works:


However, from what I remember, the issue is that regardless of what you've coded in your component, COM+ automatically manages transactions through it's Distributed Transaction Coordinator (DTC).  The selections on the tab tell DTC how to manage those automatic transactions for your particular component.  For example, DTC will automatically start a transaction whenever you call a component that is defined as "Requires" transaction (if no transaction currently exists) or always whenever "Requires New" is declared.

Now, if you didn't care about controlling your transactions at all, you could skip doing any coding for GetObjectContext.SetComplete or SetAbort (I believe) and the DTC is going to automatically commit or abort your transaction if there is not, or is a runtime error respectively... but, most people want to code their own coditions where they will commit (SetComplete) or rollback (SetAbort) the transaction.

Our general rule for developing COM+ components was to have two different classes as part of each component... the read-only interface would be declared as Uses Transactions, the update interface would Require Transaction.  In the Read Only class we wouldn't code any GetObjectContext.SetComplete or SetAbort, but in the class used for updating, every single method would perform either a SetComplete or SetAbort.  This gave us complete control over managing transactions (included nested transactions where one update object might call another update object) in our update class.
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

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

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