Transaction error...Either enlist this session in a new transaction or the NULL transaction

Transaction error...Either enlist this session in a new transaction or the NULL transaction

Post by bobbe » Tue, 24 Feb 2004 20:57:04


I am doing some database work, nothing fancy, just creating som new rows and
stuff. When I get this error.

Distributed transaction completed. Either enlist this session in a new
transaction or the NULL transaction

Exception Details: System.Data.SqlClient.SqlException: Distributed
transaction completed. Either enlist this session in a new transaction or
the NULL transaction

When I remove the ServicedComponent inheritance from my Business class
everything works great!

To ellaborate:

I have an abstract Class A which inherits from SerivcedComponetns and also
implement an Execute method, in which SubExecute is called (implemented by
class B)

Class B inherits class B and Implements SubExecute.

Both methods are tagged with [AutoComplete], and bot classes are tagged with
[Serializable] and [ Transaction(TransactionOption.Required) ]

But when any Database operations (implemented in separate layer) are called
it returns with an error!

Anybody got an idea of why

Thanks a lot!

Bge
 
 
 

Transaction error...Either enlist this session in a new transaction or the NULL transaction

Post by bobbe » Tue, 24 Feb 2004 21:29:37

I have to add that several of my database functions (both the C# code and
the stored procedures) calls Begin Transaction. Is this a problem?

Thanks!



and
also
with
called

 
 
 

Transaction error...Either enlist this session in a new transaction or the NULL transaction

Post by Mark Jen [ » Wed, 25 Feb 2004 08:45:32

Hi Bobben,

If I'm reading this correct, you have something like this:

[Transaction(TransactionOption.Required)]
public class A : ServicedComponent
{
[AutoComplete]
void Execute() {
SubExecute();
}

protected virtual SubExecute() { }
}

[Transaction(TransactionOption.Required)]
public class B : A {
[AutoComplete]
void SubExecute() {
// do work
}
}

In this case, if you create an instance of class B and call Execute, I think
that will happen is this:

1. Base class A's Execute will be called. Since TransactionOption.Required
is specified, a transaction will be created.
2. B.SubExecute will be called. Since there is already a transaction, it
will be used for the execution of SubExecute
3. Upon returning from B.SubExecute, AutoComplete will commit the
transaction.
4. Returning from A.Execute will also try to commit the transaction,
yielding the error you are seeing.

Also, if you remove the inheritance from ServicedComponent, I don't think a
transaction will actually get created in the background through COM+.

HTH,
Mark Jen [MSFT]
--
Please reply in newsgroup.
This posting is provided "AS IS" with no warranties, and confers no rights.







or
by
 
 
 

Transaction error...Either enlist this session in a new transaction or the NULL transaction

Post by Mark Jen [ » Wed, 25 Feb 2004 09:07:32

lso, calling BeginTransaction and/or using a "begin transaction" in TSQL
shouldn't cause a problem. AFAIK, those calls make a SQL local database
transaction which should then be automatically enlisted in the distributed
transaction if one exists. Thus, the outcome of the local transaction should
be dependent on the distributed transaction.

Thanks,
Mark Jen [MSFT]
--
Please reply in newsgroup.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Mark Jen [MSFT]" < XXXX@XXXXX.COM > wrote in message
news:eXBBhcm# XXXX@XXXXX.COM ...
think
a
rights.
and
rows
and
(implemented
tagged


 
 
 

Transaction error...Either enlist this session in a new transaction or the NULL transaction

Post by bobbe » Sat, 06 Mar 2004 20:03:58

hanks for your input.

I aggree with you in the way you described it.
But in B::SubExecute() i call another assembly (which is not registered with
Com+) which in turn does the actual db work.
Could this be the problem?

Bge

"Mark Jen [MSFT]" < XXXX@XXXXX.COM > wrote in message
news:ODi7zom% XXXX@XXXXX.COM ...
should
rights.
TransactionOption.Required
think
new
transaction
class