When to use TransactionOption.Supported

I have a class that requires to be in a Transaction. I therefore have given it the attribute <Transaction(TransactionOption.Required)>
My class also calls methods in other classes which do work that needs to be in the transaction.
Do I have to add an attribute to those classes as well or will they automatically be in the transaction?

If I don't have to, why would any one ever use the TransactionOption.Supported parameter?

mikexxxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DranizzCommented:
Well, if you have many objects in different assemblies that can operate seperatly and together, you can set the transaction object to supported to make them share a transaction if use together.
0
DranizzCommented:
You don't have to add option for other classes, class called in the method with the attribute will be in the transaction, if any fails and exception is thrown, than the transaction fails for all and rollbacked, if no exception is thrown, then trnsaction is commited for all.
0
DranizzCommented:
Is that good enougth?
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

mikexxxAuthor Commented:
I don't think you are correct. I have just created a transaction and called a method in another DLL. When I throw an exception, everything rolls back. The transaction must be containing what was done in the other DLL.
0
DranizzCommented:
what option did you use?
0
mikexxxAuthor Commented:
I created the transaction by having the attribute <Transaction(TransactionOption.Required)>  on the class which inherited ServicedComponent .
The class in the DLL did not inherit ServicedComponent or have any relavent attributes.
0
DranizzCommented:
Yeah, that's what I told you.
"if any fails and exception is thrown, than the transaction fails for all and rollbacked,"

Everything shares the transaction in the method where you specify the transaction option. With supported, if a transaction is already started then it shares it.

With requiredit shares a transac it exist or create one if not.
With requirednew it creates a root transac.

0
mikexxxAuthor Commented:
Yes but I was calling stuff in another assembly, without the TransactionOption.Supported
 and yet it still was contained within the transaction.

Since this is the case, my question is, why would I ever need to specify TransactionOption.Supported since it is the default.

0
DranizzCommented:

In my MCSD book, it says that the configured default value is Required with and IsolationLevel Serializable.
and the unconfigured default value is false.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgservices_transactions_9oj7.asp
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.