Trying to understand ado.net transactions

[Gandalf]

I'm trying to understand ado.net transactions and am a bit lost. What I
don't understand is, when I begin a transaction on a connection and obtain a
transaction object, why I must then pass this transaction object to command
objects that use the connection. I mean, doesn't the transaction belong to
the connection? Surely it's not possible to begin a transaction on a
connection and then execute a command on that connection outside the
transaction. Can anyone please explain the reasoning behind this?

TIA

 

[Scott Allen]

That's an interesting question. The SqlConnection class does not
support parrakeet transactions, so why shouldn't the Command object
just use the current active transaction?

My one guess is that this was a conscious design decision that forces
a developer to know when they are executing a command inside a
transaction.

 

[Nicole Calinoiu]

Actually, this is probably more a matter of compliance with the intended
behaviour of the IDbCommand interface implemented by SqlCommand. While I
can't find anything in the interface documentation that explicitly forbids a
data provider from automatically joining a command to a connection-level
transaction where there correct transaction can be properly inferred by the
provider, this behaviour certainly wouldn't be consistent with what seems to
be the intended behaviour of classes implementing the interface.

IMO, a more interesting question is why a command can't get its connection
directly from a supplied transaction...

Nicole