COM+ transaction is timing out while having serviced components

[Guest]

Hi,

Is there a way to prevent this exception?

"You made a method call on a COM+ component that has a transaction that has
already aborted or in the process of aborting."

I have been using:
System.EnterpriseServices.ServiceDomain.Enter( cfg );

to enter into a COM+ context with a transaction with a low timeout level (on
purpose), then creating an instance of a serviced component like so:

IModify imod = (IModify)Activator.CreateInstance( type );

and that's when I get the exception. Of course if I increase the timeout
level this would away in this experiment, but I need to be able to control
this issue in a production environment when even a large timeout could
timeout.

And, of course, I could catch the exception, but that's not the answer I am
looking for.

Is there no way to query the context to see if it hasn't timed out?

I have used

ContextUtil.IsInTransaction

but it returns true.

 

[Peter Huang [MSFT]]

Hi

From your description, I understand that your concern is that when in the
production environment, the COM+ component may be timeout in certain
transaction due to certain operation take too much time, so that it will
make the whole transaction to rollback.

So far I think a try..catch block is necessary to make the component more
stable. Usually we handle such timeout transaction scenario in COM+,
firstly, we need to troubleshooting what cause the problem.
e.g. here is the CreateInstance cause the problem.
then we need to evaluate if the timeout is expected and reasonable, if yes,
we need to gear the timeout value, because it is necessary for a
transaction to complete its work. if no, then we need to try to eliminate
the cause, e.g. why the CreateInstance will take such a long time?

From the exception I think it has told us that when we are calling
createinstance the transaction has been aborting, so IsInTransaction is
true.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks again Peter.

However, I think the ContextUtil.IsInTransaction does not work properly. If
the transaction is aborting or aborted then there should be a way to know
that and then avoid altogether the call to CreateInstance.

That is what I am looking for. Is there no flag for this condition so as to
avoid a call or creation of a transactional component when we already know
that the transaction has aborted?

 

[Peter Huang [MSFT]]

Hi

From the MSDN, ContextUtil.IsInTransaction Property is explained as below.
Gets a value indicating whether the current context is transactional.

So I think it is not used to detect if certain transaction is timeout.
Also I think the transaction timeout is machine level by default, certain
transation may concern about more than one machine, it is the DTC to
control the transaction work together. certain component on one macine will
not know the status other component on another machine. So it is not proper
for it to control the transaction.

So I think the component did not need to care the timeout or something in
its implement, it is the DTC's job.

For detailed information how com+ work, I think you may try to post in the
newsgroup below.
microsoft.public.dotnet.distributed_apps
or
microsoft.public.platformsdk.complus_mts

Thanks for your understanding!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.