It is my understanding that System.Transaction is the basis
of the
transactional behaviors in most of Microsoft's newer
technologies like WCF
and WF. Perhaps you weren't aware that even a business
object can be rolled
back to a previous transactional state using it (without
ADO.NET or any data
provider). This is why I stated earlier that it was much
more. Perhaps you
were focussed on the database areas of the namespace and
missed some of this
other functionality. If so, you might want to explore some
of its other
features. If not, that's cool too.
Cheers!
--Paul
_____
From: ambrogio gmail.com [mailto:ambrogiogmail.com] On Behalf Of J. Ambrose
Little
Sent: Tuesday, August 15, 2006 5:29 PM
To: aspnet-architectureaspadvice.com
Subject: [aspnet-architecture] Re: system.transaction and
webservice
confusion, please help
Oh I don't know if I agree, Paul, that System.Transactions
does much more
than ADO.NET. It can support more than that, but it's so
early on that
basically it's just Microsoft's providers that support it,
though apparently
last month Oracle released an update that does have basic
support for
System.Transactions (thanks, Steven). IIRC, only SQL 2k5
supports
promotable single phase enlistment (PSPE). Even the new
Oracle release
doesn't
<http://www.oracle.com/technology/docs
/tech/windows/odpnet/ODP.NET_10.2.0.2_
readme.txt> support that.
At this stage of the game, I wonder if System.Transactions
really adds much
value. The last time I considered it was back
<http://dotnettemplar.net/NoPromotable
SinglePhaseEnlistmentPSPEForOracle.asp
x> in April when I was working on an Oracle-based system
(when they didn't
support it at all), and it seemed to me that without PSPE,
it's not worth it
unless you're already using DTC. Since it is still the
case, my opinion is
still that unless you're primarily working with SQL 2005 or
are already
using DTC, System.Transactions is virtually unusable. But
you are right, it
is worth pointing out that it has the potential to do more
than what it
offers now.
--Ambrose
On 8/15/06, Paul Mehner <paulsoundex.com> wrote:
Also, just as a clarification to an earlier point made:
System.Transactions
does much more than just handling ADO.NET provider
transactions as stated in
an earlier post. While the post was contextually accurate
(System.Transactions couldn't solve the
webservice-participating-in-a-transaction problem without
the webservice
being transactionally aware), System.Transactions does allow
code to be
transactionified, and it also supplies automatic escalation
from lightweight
local transactions through heavier weight MSDTC transactions
(see:
http://msdn2.microsoft.com/en-us/library/system
.transactions.aspx).
System.Transactions could potentially be used as an element
of his solution.
--Paul
Need SQL Advice? http://sqladvice.com Need
RegEx Advice?
http://regexadvice.com
Need XML Advice? http://xmladvice.com
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
|