Deploying COM+ components...

[MartinSmith]

Which attributes take precedence if there are discrepancies between how a component is coded in VB and how it is configured in the Component Services MMC snap-in?

eg. If I set the MTSTransactionMode in my VB Component to "RequiresNewTransaction" but then click the Transactions "Not Supported" option in the MMC snap in how is this resolved?

If I write a component which is not intended to be stateless and do not call GetObjectContext.SetComplete or SetAbort at the end of SomeMethod() but then check the "Automatically deactivate this object when this method returns" box in the Com+ Methods property dialog what happens then?

Thanks in advance for any help!

[yrwyddfa]

Most of COM(+) is configurable. I have turned transactions off (by using Not Required) when the VB Component is marked as Required.

This stopped MS-DTC logging any statistics, and stopped the transactional nature of the component (and function calls)

[yrwyddfa]

If I write a component which is not intended to be stateless . . .

If you require transactions in COM+ the component has to be stateless.

This is because COM+ will use JIT which sods around with the garbage collection mechanisms of the object (which means you cannot guarentee state)

Also, VB/COM+ only allows 8 'real' components. So if you use state (you probably end up use Thread Local Storage) when you exceed 8 concurrent connections/function calls COM+ will start allocating objects on a round-robin fashion which means your state will be shared in a non-predictable manner.

If you need to persist state use the 'Shared Property Manager' This is more reliable, and uses basic locking premises.

[MartinSmith]

Thanks yrwyddfa.

So is there any way you know of to prevent people changing the settings?

(I notice on some of the other COM objects on my machine the options are greyed out)

Cheers,

Martin

[yrwyddfa]

I do it by controlling access to the server

[MartinSmith]

Good answer!

Cheers