I red the documention on Transaction/TransactionScope.

The example show a transaction into a transactionScope:

...

// start the scope.
using( TransactionScope ts = new TransactionScope() )
{
    // start a new LLBLGen Pro transaction
    using( Transaction trans = new Transaction(System.Data.IsolationLevel.ReadCommitted, "Test") )
    {
        newCustomer.VisitingAddress = newAddress;
        newCustomer.BillingAddress = newAddress;
        // add the entities to save to the LLBLGen Pro transaction
        trans.Add( newCustomer );
        trans.Add( newAddress );
        // save both entities.
        Assert.IsTrue(newCustomer.Save( true ));
    }
    // do not call Complete, as we want to rollback the transaction and see if the rollback indeed succeeds.
    // as the TransactionScope goes out of scope, the on-going transaction is rolled back.
}

...

When I read documentation about transactionScope, I'm not able to find why you put the transaction into a transactionScope and/or why having used a transaction scope in this situation. Also, I wonder why don't you give a complete real life example with the commit and/or the transactionScope.Complete() ? ... following those concerns, I got some questions:

1 - Is the transactionScope is needed for having a transaction ? (I think not, can you confirm) ? 2 - Why adding a transactionScope if we already have a transaction and only have one ? 3 - Why not using only a transactionScope without a LLBLGen transaction object (samples on the web do not seems to use another inner transaction object) ? 4 - Do you have complete working example of with-and-only-with transaction 5 - Do you have complete working example of one with-and-only-with transactionScope 6 - Do you have complete working example of another one with both (the one in documentation do not include commit() or complete() ?

Please note that I am not interresting in unit of works.

Thanks Eric

Hi Eric, I will try to answer your questions.

Wally wrote:

... When I read documentation about transactionScope, I'm not able to find why you put the transaction into a transactionScope and/or why having used a transaction scope in this situation. Also, I wonder why don't you give a complete real life example with the commit and/or the transactionScope.Complete() ? ... following those concerns, I got some questions:

The code snippet in the documentation is for explanation purposes. The concept and usage is very clear in my opinion. Read more about the tech behind this TransacionScope thing: http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx

Wally wrote:

1 - Is the transactionScope is needed for having a transaction ? (I think not, can you confirm) ?

No, it is not. You use TransactionScope if you need transactions elevated to distributed transactions.

Wally wrote:

2 - Why adding a transactionScope if we already have a transaction and only have one ?

The transaction is elevated to distributed transaction. Check this for more info: http://msdn.microsoft.com/en-us/library/0abf6ykb.aspx

Wally wrote:

3 - Why not using only a transactionScope without a LLBLGen transaction object (samples on the web do not seems to use another inner transaction object) ?

Not needed. Also, not every DB out there support this.

Wally wrote:

4 - Do you have complete working example of with-and-only-with transaction

No, but many examples use them in the code. And transaction are used always implicitly.

Wally wrote:

6 - Do you have complete working example of another one with both (the one in documentation do not include commit() or complete() ?

No, but you can copy-paste it and test it your self with Complete uncommented.

Wally wrote:

Please note that I am not interresting in unit of works.

I don't understand what are you looking for. what are you trying to achieve?

Hello Daelmo,

I don't understand what are you looking for. what are you trying to achieve?

To be honest, I found the sample in the documentation totally inappropriate. It mix and match 2 transactions type (transaction and transaction scope). It serve more to mix people than to help them (this is my opinion). To me, it would happen in very rare case. Plus the example do not have the necessary "TransactionScope.Complete"... The sample is not complete at all and seems to be contructed on the fly just to fill the blank !!! (yes i'm straight and direct... see at the end).

There is no reason to include a transaction into a transactionScope if you don't do a save on the transaction in the middle and/or you do not use more than on DB. I think it should be clearly stated !!!

Unit of works is not fully transactionnal. The LLBLGen support, pushes Unit of works a lot but there is something missing in that, something very important. It should also include "select" or if you prefer "GetMulti()". You can do cool stuff with UnitOfWork but for me it is only a gadget. A transactionnial system should include "GetMulti()" too to ensure coherence. I already mention that. That's why I said I'm not interested in unitOfWork.

About, transaction scope. I red few articles about it before writing this critic (yes it is a real critic). In fact it is because I found the documention a little bit weird and it forces me to read few articles and I still don't understand what was the author intention. I still don't understand the idea behind the sample.

... Yes I critics a lot !!! But I loose my time only on think that I highly think it worth it !!! If I didn't believe that LLBLGen is very nice, I would never loose a minutes to write here. I do that to try to improve the product. I'm little too direct and straight! Yes! I'm stuck with very few time and so much works to do !!!

Thanks for your prompt and nice support ! It is not really important if nothing change. I only try to improve when I think it could worth it.

Wally wrote:

Hello Daelmo,

I don't understand what are you looking for. what are you trying to achieve?

To be honest, I found the sample in the documentation totally inappropriate. It mix and match 2 transactions type (transaction and transaction scope). It serve more to mix people than to help them (this is my opinion). To me, it would happen in very rare case. Plus the example do not have the necessary "TransactionScope.Complete"... The sample is not complete at all and seems to be contructed on the fly just to fill the blank !!! (yes i'm straight and direct... see at the end).

Please don't take this the wrong way but... I have the feeling you don't really fully understand what TransactionScope actually does. It doesn't actually provide a transaction, it just offers the ability to a) group transactions into 1 transaction and b) offer (if supported by the DB!) the usage of lightweight distributed transactions instead of MS DTC based distributed transactions. That's it.

To show this in action, we deliberately made an example which opens a transaction manually, to show what's going on. Sure, we could have opted for a SaveEntity() call and be done with it, but that doesn't really illustrate the point as the reader then has to realize that there is a transaction started implicitly by SaveEntity.

There is no reason to include a transaction into a transactionScope if you don't do a save on the transaction in the middle and/or you do not use more than on DB. I think it should be clearly stated !!!

that's not true. In fact, transactionscope is not needed if you don't use more than one transaction which have to be used as 1 transaction. After all, transactionscope still relies on ADO.NET transactions, it doesn't do anything that clever.

Actually, we have to help the transactionscope with a resourcemanager to let it keep track of what's going on.

Unit of works is not fully transactionnal. The LLBLGen support, pushes Unit of works a lot but there is something missing in that, something very important. It should also include "select" or if you prefer "GetMulti()". You can do cool stuff with UnitOfWork but for me it is only a gadget. A transactionnial system should include "GetMulti()" too to ensure coherence. I already mention that. That's why I said I'm not interested in unitOfWork.

isn't this more about transaction isolation? Why else would anyone be interested in selects during transactions? Also, selects aren't work to be done on the data, they're not DML oriented, the purpose of UoW.

About, transaction scope. I red few articles about it before writing this critic (yes it is a real critic). In fact it is because I found the documention a little bit weird and it forces me to read few articles and I still don't understand what was the author intention. I still don't understand the idea behind the sample.

It's simple. The sample is to illustrate that you can wrap your normal transaction code with a transaction scope and automatically benefit from the service provided by the transactionscope. that's it because there's nothing more. That's what a transactionscope does: group several ado.net transactions in a single transaction and if possible use lightweight distributed transactions instead of the more heavy MS DTC stuff.

The complete isn't there because it's a full example. It's right there in the comments:

// do not call Complete, as we want to rollback the transaction and see if the rollback indeed succeeds. // as the TransactionScope goes out of scope, the on-going transaction is rolled back.

that's also why the traces are still there so the user can see it in action. For transactionscope documentation, MSDN is the main source. We just wanted to show that it's simple to use, just wrap your own code with the transactionscope code and it's done (and call Complete in the end, which is actually a very simple method, as it gathers all Ado.net transaction results and if there's one rollback, it will rollback all transactions. That's code we had to write and offer in the framework behind the scenes to the transactionscope. That's the benefit we offer to you: entity state is rolledback, even though you committed a transaction inside the scope. That's also what the example wanted to show.

... Yes I critics a lot !!! But I loose my time only on think that I highly think it worth it !!! If I didn't believe that LLBLGen is very nice, I would never loose a minutes to write here.

We know, Eric, no worries