Automatic transactions using TransactionOption attributes

[ranga]

this question related to the architecture of distributed apps that require
transactions - using C#, VS.NET 2003, SQL2000

That is, a single asmx file can have several webmethods each having a
different
TransactionOption attribute. If I use this attribute to get
automatic-transactions, how does ASP.NET accomplish this without using COM+ ?

Option 1 : - Use WebMethods (for insert/uddate/delete) with
TransactionOption attribute
- the Webmethod contains ADO.NET code
- drawback is that ADO.NET code is exposed in the webmethod
- question in my mind is : since COM+ is not used here, what
are the
drawbacks of this option. Is this a scalable option?.

Option 2: - Use WebMethods (for insert/update/delete) with
TransactionOption attribute
- put the ADO.NET code in a simple dll (non serviced component)
- Webmethod calls the classes in the dll
--advantage : ADO.NET code is not exposed in asmx files

option 3: - Use WebMethod without TransactionOption attribute
- put the ADO.NET code in a dll that has serviced components
- register the dll in com+
- webmethod calls the serviced component classes hosted in COM+
- complex option - com+ registration/management is difficult
-- what are the advantages of this option ?. Can i live without
com+
and use option 1 -- does this option give me any advantage
over
option 1 and 2 ?

of 25-50 users if option-1 and 2 are sufficient to get the advantage of
automatic transactions and not have the complexity of com+/serviced
components.

thanks
ranga

 

[Dilip Krishnan]

Hello ranga,

transactions - using C#, VS.NET 2003, SQL2000

That is, a single asmx file can have several webmethods each having a
different
TransactionOption attribute. If I use this attribute to get
automatic-transactions, how does ASP.NET accomplish this without using
COM+ ?
Option 1 : - Use WebMethods (for insert/uddate/delete) with
TransactionOption attribute
- the Webmethod contains ADO.NET code
- drawback is that ADO.NET code is exposed in the
webmethod
- question in my mind is : since COM+ is not used here,
what
are the
drawbacks of this option. Is this a scalable option?.

TransactionOption in the web method inturn uses Enterprise Services ie. COM+

Option 2: - Use WebMethods (for insert/update/delete) with
TransactionOption attribute
- put the ADO.NET code in a simple dll (non serviced
component)
- Webmethod calls the classes in the dll
--advantage : ADO.NET code is not exposed in asmx files

This just achieves seperation of reponsibilities and layers your application.

option 3: - Use WebMethod without TransactionOption attribute
- put the ADO.NET code in a dll that has serviced
components
- register the dll in com+
- webmethod calls the serviced component classes hosted
in COM+
- complex option - com+ registration/management is
difficult
-- what are the advantages of this option ?. Can i live
without
com+
and use option 1 -- does this option give me any
advantage
over
option 1 and 2 ?

In this method yr moving from the .net world to the COM+ world. There is
always going to be a performance hit that goes with COM+ interop.

of 25-50 users if option-1 and 2 are sufficient to get the advantage
of automatic transactions and not have the complexity of com+/serviced
components.

thanks
ranga

HTH
Regards,
Dilip Krishnan
MCAD, MCSD.net
dkrishnan at geniant dot com
http://www.geniant.co

 

[ranga]

TransactionOption in the web method inturn uses Enterprise Services ie. COM+
-- then why do we have to write serviced components at all?

In this method yr moving from the .net world to the COM+ world. There is
always going to be a performance hit that goes with COM+ interop.

-- true, but if i want to use automatic transactions, then which method
should i use
and in what scenarios is the question -- webmethods with Transaction
attribute or Webmethods without transaction attributes calling Serviced
components hosted in com+ ??

 

[Dilip Krishnan]

Hello ranga,
Again you write serviced components for seperation of responsibilities
read (tiers, logical or otherwise) [http://www.hanselman.com/blog/PermaLink.aspx?guid=a0a65e0c-5ef8-41e4-a566-1739b4428aa5],
[http://www.tonymarston.net/php-mysql/oop-for-heretics.html]. It wouldnt
be a good idea to use the transaction optiin in a web service because then
yr exposing the ability of controlling transaction to the client.. since
transaction is so expensive, thats not really a good idea. Another thing
to consider is you are going to pay the same performance penalties for using
the com+ interop either case.
You would only use the transaction option in trusted environments. i.e.
Intranet web service etc. where you know all the consumers of the service.

HTH
Regards,
Dilip Krishnan
MCAD, MCSD.net
dkrishnan at geniant dot com
http://www.geniant.com

 

[Dan Rogers]

It's reallly not a great idea to design web services this way - IMO. The
best performance/reliablity is going to be seen when you have a method be a
complete transaction unto itself, and not rely on any coupling at the
client to control other methods being successful.

The notion of atomic transactions maps very cleanly to a single web method
- and as a rule, consider resisting any request to make automatic, or two
phase commit requirements span web method boundaries. In short, the client
should not assume that it has a right to control the span of a two phase
commit transaction in a distributed environment - be it web services, or be
it CORBA, etd.

The transaction option you find on web methods controls how the method
communicates internally to the COM+ subsystem. If you set the transaction
option on, any calls made within the body of the method are made in a new
transaction context - and that context is shared (potentially) with any
called enterprise service or transactional com+ components within the
boundary of your single web service. The transaction context will NOT span
to the client, nor will it span other web service/method calls made by your
web service via a proxy class.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------

Thread-Topic: Automatic transactions using TransactionOption attributes
thread-index: AcTxzh0j32LlW0FxRHSxYeBCZItO/w==
X-WBNR-Posting-Host: 24.1.83.164
From: "=?Utf-8?B?cmFuZ2E=?=" <[email protected]>
Subject: Automatic transactions using TransactionOption attributes
Date: Mon, 3 Jan 2005 11:55:02 -0800
Lines: 47
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.aspnet.webservices:27467
X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
require
transactions - using C#, VS.NET 2003, SQL2000

ServicedComponent in System.EnterpriseServices), the transaction attribute
(Required,Supported etc) can be applied only at the class level (ie all
methods of the class can have only one and the same transaction attribute)
but the application of this attribute in a Webmethod is more granular-
instead of it being at the class level it is at the method level.

That is, a single asmx file can have several webmethods each having a
different
TransactionOption attribute. If I use this attribute to get
automatic-transactions, how does ASP.NET accomplish this without using COM+ ?

transactions, i can think of the following options.

Option 1 : - Use WebMethods (for insert/uddate/delete) with
TransactionOption attribute
- the Webmethod contains ADO.NET code
- drawback is that ADO.NET code is exposed in the webmethod
- question in my mind is : since COM+ is not used here, what
are the
drawbacks of this option. Is this a scalable option?.

Option 2: - Use WebMethods (for insert/update/delete) with
TransactionOption attribute
- put the ADO.NET code in a simple dll (non serviced component)
- Webmethod calls the classes in the dll
--advantage : ADO.NET code is not exposed in asmx files

option 3: - Use WebMethod without TransactionOption attribute
- put the ADO.NET code in a dll that has serviced components
- register the dll in com+
- webmethod calls the serviced component classes hosted in COM+
- complex option - com+ registration/management is difficult
-- what are the advantages of this option ?. Can i live without
com+
and use option 1 -- does this option give me any advantage
over
option 1 and 2 ?

attribute in WebMethods to get automatic transactions and when to use
webmethods and com+ both to get automatic transactions? and what are the
pros and cons of both these optionsmanagement in terms of object pooling etc but want to know for a small
userbase