EnlistDistributed Transaction Error - An event was unable to invoke any of the subscribers

  • Thread starter Thread starter Chris Dawson
  • Start date Start date
C

Chris Dawson

Just applied SP1 for v1.1 of the .NET Framework, and we're receiving
the following error message when closing a SqlConnection, that has
been manually enlisted in a distributed transaction:

An event was unable to invoke any of the subscribers

Server stack trace:
System.Runtime.InteropServices.COMException
at System.Runtime.InteropServices.UCOMIConnectionPoint.Advise(Object
pUnkSink, Int32& pdwCookie)
at System.Data.SqlClient.ConnectionPool.PutConnectionManualEnlisted(SqlInternalConnection
con)
at System.Data.SqlClient.ConnectionPool.PutDeactivatedConnection(SqlInternalConnection
con)
at System.Data.SqlClient.SqlConnection.Close()
at System.Data.SqlClient.SqlConnection.Dispose(Boolean disposing)

The server is a Windows 2000 Server, with SP3 applied. Has anyone
else ran into this? I noticed one other post about this on
08/19/2004:

http://groups.google.com/groups?hl=...invoke+any+of+the+subscribers%22+COMException

But the user was running on Windows 2003 or XP, and was utilizing the
ServiceDomain class. We're not doing utilize either of these.

Any help would be greatly appreciated.

- Chris
 
I was not able to repro the issue on the thread you are linking to and I did
not hear anything more about the issue.

I assume from your post that your application was working with v1.1 and only
started failing when you moved to SP1? My minimum configuration for Windows
2003 uses SP4, I was lead to believe that this was required for Distributed
Transactions. I can try to repro this in-house if you have any code I could
use.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
Angel,

Thanks for the response. No, the code was not working prior to SP1 of
the Framework, which is the reason we applied the service pack.
Here's the scenario we were running into prior to applying the service
pack:

When running on Windows 2000, create a serviced component and register
it in COM+ inside of a Library Application. If you manually enlist
the transaction, utilizing EnlistDistributedTransaction (and assuming
you have Enlist=false in the connection string), the method you
invoked on the ServicedComponent will never return. It just hangs
indefinitely. If the COM+ Application is configured as a Server
Application, the code executes fine.

After applying the service pack, this issue was resolved. However,
we're now experiencing the "An event was unable to invoke any of the
subscribers" error. It seems to be when the root transactional
object, creates more than one ServicedComponent.

The code is very vanilla, nothing out of the ordinary. All of the
ServicedComponents are marked as Requires Transaction, and Just In
Time Actication set to true. I can send you a sample, would like me
to email it to (e-mail address removed)?

Thanks for you help on this.

Chris

Angel Saenz-Badillos said:
I was not able to repro the issue on the thread you are linking to and I did
not hear anything more about the issue.

I assume from your post that your application was working with v1.1 and only
started failing when you moved to SP1? My minimum configuration for Windows
2003 uses SP4, I was lead to believe that this was required for Distributed
Transactions. I can try to repro this in-house if you have any code I could
use.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Chris Dawson said:
Just applied SP1 for v1.1 of the .NET Framework, and we're receiving
the following error message when closing a SqlConnection, that has
been manually enlisted in a distributed transaction:

An event was unable to invoke any of the subscribers

Server stack trace:
System.Runtime.InteropServices.COMException
at System.Runtime.InteropServices.UCOMIConnectionPoint.Advise(Object
pUnkSink, Int32& pdwCookie)
at System.Data.SqlClient.ConnectionPool.PutConnectionManualEnlisted(SqlInternal
Connection
System.Data.SqlClient.ConnectionPool.PutDeactivatedConnection(SqlInternalCon
nection
con)
at System.Data.SqlClient.SqlConnection.Close()
at System.Data.SqlClient.SqlConnection.Dispose(Boolean disposing)

The server is a Windows 2000 Server, with SP3 applied. Has anyone
else ran into this? I noticed one other post about this on
08/19/2004:

http://groups.google.com/groups?hl=...invoke+any+of+the+subscribers%22+COMException

But the user was running on Windows 2003 or XP, and was utilizing the
ServiceDomain class. We're not doing utilize either of these.

Any help would be greatly appreciated.

- Chris
Click to expand...
Click to expand...
 
Chris, I would like to take a look at the code, you can send it at the email
below without the .online.

I am not aware of any fixes in ado.net for distributed transactions in SP1,
are you saying that you applied it to get EnterpriseServices fixes? Could
the problem be that you are using Windows 2000 SP3 instead of SP4? I am not
sure if there where DTC fixes in SP4, but when I talked to the enterprise
service folks they led me to believe that was the minimum requirement.

Can you auto enlist the connection in the dtc (Enlist=true)? My concern is
that this sounds like a DTC set up issue and I am definitely not the best
person to ask about this...

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Chris Dawson said:
Angel,

Thanks for the response. No, the code was not working prior to SP1 of
the Framework, which is the reason we applied the service pack.
Here's the scenario we were running into prior to applying the service
pack:

When running on Windows 2000, create a serviced component and register
it in COM+ inside of a Library Application. If you manually enlist
the transaction, utilizing EnlistDistributedTransaction (and assuming
you have Enlist=false in the connection string), the method you
invoked on the ServicedComponent will never return. It just hangs
indefinitely. If the COM+ Application is configured as a Server
Application, the code executes fine.

After applying the service pack, this issue was resolved. However,
we're now experiencing the "An event was unable to invoke any of the
subscribers" error. It seems to be when the root transactional
object, creates more than one ServicedComponent.

The code is very vanilla, nothing out of the ordinary. All of the
ServicedComponents are marked as Requires Transaction, and Just In
Time Actication set to true. I can send you a sample, would like me
to email it to (e-mail address removed)?

Thanks for you help on this.

Chris

"Angel Saenz-Badillos[MS]" <[email protected]> wrote in message
I was not able to repro the issue on the thread you are linking to and I did
not hear anything more about the issue.

I assume from your post that your application was working with v1.1 and only
started failing when you moved to SP1? My minimum configuration for Windows
2003 uses SP4, I was lead to believe that this was required for Distributed
Transactions. I can try to repro this in-house if you have any code I could
use.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Chris Dawson said:
Just applied SP1 for v1.1 of the .NET Framework, and we're receiving
the following error message when closing a SqlConnection, that has
been manually enlisted in a distributed transaction:

An event was unable to invoke any of the subscribers

Server stack trace:
System.Runtime.InteropServices.COMException
at System.Runtime.InteropServices.UCOMIConnectionPoint.Advise(Object
pUnkSink, Int32& pdwCookie)
at
Click to expand...
System.Data.SqlClient.ConnectionPool.PutConnectionManualEnlisted(SqlInternal
Connection
con)
at
Click to expand...
System.Data.SqlClient.ConnectionPool.PutDeactivatedConnection(SqlInternalCon
nection
con)
at System.Data.SqlClient.SqlConnection.Close()
at System.Data.SqlClient.SqlConnection.Dispose(Boolean disposing)

The server is a Windows 2000 Server, with SP3 applied. Has anyone
else ran into this? I noticed one other post about this on
08/19/2004:
Click to expand...
http://groups.google.com/groups?hl=...invoke+any+of+the+subscribers%22+COMException
But the user was running on Windows 2003 or XP, and was utilizing the
ServiceDomain class. We're not doing utilize either of these.

Any help would be greatly appreciated.

- Chris
Click to expand...
Click to expand...
Click to expand...
 
Angel,

Yes, we applied the service pack for v1.1 of the Framework, with the
hope that it would address the initial problem we were having with
EnlistDistributedTransaction (the code execution never returning after
calling a method on a ServicedComponent that resides in a Library
Application).

We had installed the beta for SP1, and it seemed to fix the problem. So
we made an assumption that the service pack addressed this issue.

I installed Service Pack 4, for Windows 2000, on our development server
yesterday and we're still having the same problem. Also, just to
clarify, this is not isolated to one machine. I can reproduce this on
other machines as well. Which would lead me to believe that it's not an
installation issue with DTC (just my opinion).

Yes, we can auto-enlist the transaction (which is the workaround we went
with in the interim a few months back, because of the problem we had
with EnlistDistributedTransaction). It's a hack, but the areas of the
code were we don't need a transaction, we have a separate connection
string with Enlist=False. This isn't exactly the best way to handle it,
given the fact that there will be two different connection pools for the
same database.

I'll email the code to you right away. I sent the original issue to
Gert Drapers awhile back and didn't receive a response. I'll forward
you the email, with the attached source code, that I sent to Gert.
Hopefully you can help shed some light on this issue.

Chris
 
AKarthi,
I take it that you are running into the same issue? Do you have a standalone
app that repros the problem? Please make sure to describe your environment.
I got the coe from Chris Dawson and I was not able to repro the problem that
he was running into. I am afraid that I am doing something wrong and
completelly missing the bug here.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
Sorry for this late reply. I was busy work on one of our projects production
release. I will post the sample code soon. Thanks.

Angel Saenz-Badillos said:
AKarthi,
I take it that you are running into the same issue? Do you have a standalone
app that repros the problem? Please make sure to describe your environment.
I got the coe from Chris Dawson and I was not able to repro the problem that
he was running into. I am afraid that I am doing something wrong and
completelly missing the bug here.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




AKarthi said:
Angel,
Any update on this issue?

Thanks
Click to expand...
Click to expand...
 
Back
Top