Using distributed transactions in .Net 1.x without deriving from ServicedComponent

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Milo — Wed, 28 Jul 2004 04:13:00 GMT

Hi

Has anyone managed to try this code successfully and change the isolation level? ie. Something like:
objServiceConfig.IsolationLevel=EnterpriseServices.TransactionIsolationLevel.ReadUncommitted

It seems to work nicely untill you try to change the isolationlevel (the stting is ignored).

Regards
Milo

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Alex Thissen — Wed, 04 Aug 2004 08:43:00 GMT

Nice entry.
This also works with XP SP1 if you have the appropriate Windows Update provided fixes installed. See also my blog-entry: http://www.alexthissen.nl/Weblog/PermaLink.aspx?guid=f6d61461-d336-40b0-9f4d-51eab6650f27. FWIW, there is also an entry on TIP transactions using ServiceConfig and ServiceDomain.

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Enrico Sabbadin — Wed, 04 Aug 2004 12:45:00 GMT

Hi,
personally I think that what's great about MTS-style transactions is that they are declarative, not that they are distributed.
Not quite often you need to target different stores. On the other hand, declarative transaction keep you domain/model - business/layer far from database transactions details. I think one typically thinks about transactions in term of business-application level transactions, not database transactions; that's why declarative transactions are so great...
I've used mts style transaction a logt in COM despite their impact on perfomances, however in my opinion using servicedcomponents in net 1.1 has so many twists and turns , and deploymenent requirements and bugs and .. that I had to drop it.
The solution proposed here is very interesting and drops all these twist and turns. Unfortunately the problem is that it isn't declarative stuff any more.. so it's ok for distributed transactional needs "only".

I developed a custom .NET data provider on my own to make transaction flow transparent to business-layer code .. you can find more info in my blog.

my 2 cents
enrico

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Enrico Sabbadin — Wed, 04 Aug 2004 12:54:00 GMT

I forgot to say that obviously I'd like a [Transaction.Required] attribute that spins up a local transaction and promote to distributed only when needed.
Is this supposed to be supported on .net 2.0 ?

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Marcelo Lavio — Fri, 06 Aug 2004 13:51:00 GMT

Hi,

To Milo: Yes, I've changed successfully the TxIsolationLevel but to ReadCommitted (I never tried to change it to ReadUncommitted). So, i can say that, in general, changind the TxIsolationLevel works. But, if ReadUncommitted setting got ignored, it may be due to a bug on COM+ transactional services handling this kind of setting.

To Florin: I'm trying the approach suggested here (using the ESTransactionScope class) on a project I'm working on. The code is nice, but I think a little change to the ESTransactionScope class is in order:

If, for some reason, ServiceDomain.Enter() call on the EnterTxContext() method throws an exception, there will be no way to match the ServiceDomain.Enter() with a corresponding ServiceDomain.Leave() as required on the remarks of the ServiceDomain class overview (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemEnterpriseServicesServiceDomainClassTopic.asp).

My suggestion is that the ESTransactionScope constructor shall only set the ServiceConfig object (like, for instance, the constructor of SqlConnection, which can be used to set up the connection string). Then the class should have Open() method (to set an IsOpen boolean private flag and call ServiceDomain.Enter()) and Close() method (to, if the IsOpen flag is true, set the IsOpen flag to false and call ServiceDomain.Leave()). The Dispose() method can then be changed to just call Close().

That's my 2 cents.
Marcelo

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Marcelo Lavio — Sat, 07 Aug 2004 13:59:00 GMT

Hi Florin,

I've done a deeper testing on COM+ Services Without Components and this ESTransactionScope class, and I found what I think is an important flaw on COM+ 1.5 SwC implementation.

This is the situation: supose three "components", all of them are transactional (transaction required). Let's say that one component has a method that is the transaction root (let's call it Component1.MethodTransactionRoot) and this method calls one method on the second component (Component2.MethodNestedCall1), and then a method on the third component (Component3.MethodNestedCall3) as per the following pseudo code:

// on client
static void Main(string[] args) {
for (int i = 0; i < 3; i++) {
try {
Component1 component1 = new Component1();
component1.MethodTransactionRoot();
catch (Exception e) {
Console.WriteLn(e.ToString());
}
}
}

// on Component1
public void MethodTransactionRoot() {
Component2 component2 = new Component2();
component2.MethodNestedCall1();
Component3 component3 = new Component2();
component3.MethodNestedCall2();
}

// on Component2
public void MethodNestedCall1() {
// do some transaction, vote for abort but do not throw an exception
// if this is a serviced component deactivate it on return
}

// on Component3
public void MethodNestedCall2() {
// do some transaction and vote for commit
// if this is a serviced component, deactivate it on return
}

If all this three components are traditional ServicedComponents (extending System.EnterpriseServices.ServicedComponent), at the time Component1.MethodTransactionRoot() calls Component3.MethodNestedCall2() you got an System.Runtime.InteropServices.COMException ((0x8004E003): You made a method call on a COM+ component that has a transaction that has already aborted or in the process of aborting.) as expected as the code in Component2.MethodNestedCall2 is bad code, because it didn't throw an exception, so the calling code tried to continue using a doomed transaction.

But, besides that, as the Main() method continues to call Component1.MethodTransactionRoot(), every thing is the same, over and over again, as it should.

The behaviour is completelly different if the code, instead of ServicedComponent, uses COM+ 1.5 SwC on each of the three components (where each "transactional" method calling ServiceDomain.Enter() and ServiceDomain.Leave()). As expected the same COMException will be thrown, at the same point in code, on the first call of the Main() method to the Component1.MethodTransactionRoot(). But all the other calls will fail when Component1.MethodTransactionRoot() calls ServiceDomain.Enter() again, when executing the other calls made from Main() method.

The point is that if you call ServiceDomain.Enter() on a doomed transaction (a transaction that is aborting), you enter a non recoverable state that will prevent any furter success call to ServiceDomain.Enter() until you shutdown your application and then restart. This is much different than the behaviour of traditional ServicedComponents, and I consider it a flaw.

As there is no fail safe way to detect if you are running a doomed transaction before make a call to ServiceDomain.Enter(), if any point of application code is sloppy (does not throw an exception when it votes for transaction abort), you risk to put the whole application down until next application restart.

As per my tests, every call to ServiceDomain.Enter() creates a new COM+ Context (verified by calls to ContextUtil.ContextId), and every call to ServiceDomain.Leave() terminates that context.

The problem happens when ServiceDomain.Enter() is called in a context which has a doomed transaction. The implementation of ServiceDomain.Enter() does some wrong thing in context management, and no call to ServiceDomain.Leave will be able to terminate the contexts that were created by the previous calls to ServiceDomain.Enter(). You can verify that using sucessive calls to ServiceDomain.Leave(); ContextUtil.ContextId; which returns the same ContextId over and over again (with transactional status 'Committed').

Hope you can tell if this behaviour is "by design" or that you can carry this info to someone at Microsoft for further investigation.

Thanks,
Marcelo Lavio

PS.: Platform of tests is Windows 2003 Server, COM+ 1.5, .NET 1.1. I can send test code which demonstrates the problem. If interested, plese write to mlavio (at) hotmail dot com.

Databases, MSMQ, [you name a resource manager] and Services Without Components

Christian Weyer: Smells like service spirit — Tue, 14 Sep 2004 21:16:00 GMT

Distributed Transactions

gxh973121 — Wed, 05 Jan 2005 04:21:00 GMT

Ping Back来自：blog.csdn.net

Using distributed transactions in .Net 1.x without deriving from ServicedComponent

xdev — Wed, 05 Jan 2005 10:32:00 GMT

Ping Back来自：blog.csdn.net

Distributed Transactions

gxh973121 — Mon, 07 Mar 2005 09:17:00 GMT

TrackBack From:http://www.cnblogs.com/gxh973121/archive/2005/03/07/114394.html

Using distributed transactions in .Net 1.x without deriving from ServicedComponent

coollzh — Wed, 09 Mar 2005 18:45:00 GMT

TrackBack From:http://www.cnblogs.com/coollzh/archive/2005/03/09/115813.html

Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Wes Shaddix — Thu, 10 Mar 2005 19:58:00 GMT

Transaction.Current and Ambient Transactions

Florin Lazar's WebLog — Tue, 19 Apr 2005 10:09:06 GMT

Ambient transactions are defined as transactions that live in current thread or object context that anybody...

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

YeYan — Tue, 17 May 2005 02:36:55 GMT

RePost:
http://www.yeyan.cn/Database/distributedtransactionsderivingServicedComponent.aspx

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

florinlazar — Sat, 21 May 2005 03:46:06 GMT

To: M. Lavio

The bug that you are mentioning about calling Enter on an aborted transaction it is now fixed in Windows Server 2003 SP1. It will be also fixed in XP SP3. If you need the fix sooner, you can call Microsoft Support and ask for COM+ Rollup 9 for Windows XP.

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

rjn — Sun, 28 Aug 2005 15:14:28 GMT

Florin,
My application is running on windows2000,so serviceconfig won't work. You suggested using DonBox's approach at this url. http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-07-12T08:40:44Z
I'm unable to find this url. Can you post the correct url please.
Thanks

Enterprise Services: Some Light Reading

Kirk Allen Evans' Blog — Thu, 16 Feb 2006 06:33:51 GMT

Yeah, I am back on the ES kick again.&nbsp; Some EnterpriseServices links to ponder.
Using Distributed...

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

Michael Herman (Parallelspace) — Thu, 13 Jul 2006 03:01:37 GMT

A naive question: If instead of using a console app for this demo, can I use/call ESTransactionScope() inside a .NET 1.1 ASMX Web service [WebMethod]? Anything special I have to do? Part of my question is: do I have declare any special threading attributes (e.g. [MTAThread]) anywhere in my ASMX Web service class?

re: Using distributed transactions in .Net 1.x without deriving from ServicedComponent

florinlazar — Wed, 04 Oct 2006 04:13:45 GMT

To: Michael

No, nothing special as far as I'm aware of.