Implicit Transactions

My understanding of the Services layer is that it will look for transcation in the current thread of execution.  If it finds one, it will use it.

Before adopting the Services layer, I have some concerns with the implicit transaction behavior.  If there was problem domain that required multiple data sources, it is possible to have two transaction at work.  Assume each transaction was correlated with different data sources.  For things to work property, the instances of a transaction manager would have to be passed explicitly to the services layer.  The data access layer allows for explicit transaction passing.

 If I have misunderstood the mechanics, or there is a trivial work around to alleviate my fears, my curious mind would like to know.

I'd prefer the TransactionScope instead even if it is a breaking change. It is perhaps possible to generate code using TransactionScope when choosing to generate SQL Server 2005 specific code and to use the old TransactionManager when generating non SQL Server 2005 specific code.

We will see about doing this, I think i'm for it as well.

One of the other breaking changes, is the IsolationLevel enum, which is now duplicated in the .net Framework, in System.Data and System.Transactions.  Lame!

Hello,

When you say its easy to subsitute TransactionScope in for the DbTransaction that gets created off of the connection, is that before or after the code has been generated?

I'm looking at code already generated and it seems a little difficult as all of the inserts, updates, deletes use the TransactionManager's DbTransaction object...passing it to the Enterprise Library data access methods as arguments. Changing it means that all of the general dataccess methods which expect the transaction must not be called and the overloads called instead.

In short, its a lot of changes...and the way transactionscope works - all of the calls to commit or abort down in the dataproviders will potentially cause errors if another operation tries to participate in the same transaction after it has been aborted. Per this thread .

Robert Hinojosa:

Hi,

 

It's actually quite easy to substitute the Transaction in TransactionManager to using the new TransactionScope type, which can manage transactions to multiple databases.  It requires are reference to System.Transactions.dll , and would be a rather large breaking change, which is why we haven't implemented it.

 

This though requires SQL2005.

Just an update on this. Using WCF NetMSMQBinding, the service contract requires a transactionscope. If you do not, you could lose the message. That transactionscope flows from the distributed transaction MSMQ creates as the message is read out of the queue on down to the service contract operation.

 What happens is this...

1) WCF receives message in queue

2) MSMQ, transaction queue - creates a System.Transactions.Transaction as the message moves from queue to service.

3) Service is decorated with 

[OperationBehavior(TransactionAutoComplete=true,TransactionScopeRequired=true)]

4) Call to update an entity is made through the component layer.

5) Component layer calls transactionManager = ConnectionScope.ValidateOrCreateTransaction();

6) XXXConnection does not support parallel transactions. Exception thrown.

Without commiting the original distributed transaction before making the call to save, I don't see an elegant way around this. I tried checking inside ConnectionScope- if there is an ambient transaction, don't create one. That works great until you get to the provider level which checks the transaction before it performs an update (or insert, etc) - if its null, it creates one - and we blow up again.

 Who has dealt with this before? Anyone using NetTiers with distributed transactions at the enterprise level?

Any update on this ? Is support for System.Transactions on roadmap of NetTiers ?

Thanks 

The work around to this to make a breaking change to the .Data project and to the entities project. Add in System.Transactions as a reference to those projects and in ConnectionScope.cs and the TransactionManager.cs make checks for an ambient transaction in the appropriate places. I think I only need to make this check in 2 places.

 If it has an ambient transaction, I don't create one. Realize though that since you are dealing with a SQL connection AND MSMQ's initial transaction as the transaction root - you will ALWAYS have a distributed transaction, not one of the lightweight transactions System.Transactions supports.

 .Net Tiers also uses Ent Lib 2.0 which does not really support System.Transactions. Currently, if you create a System.Transactions transaction on top of the service layer or domain layer - a new database connection is created, recycled, etc. This will cause System.Transactions to promote to a distributed transaction because it is not on the same connection.With Ent Lib 3.0, they reuse the same connection on most calls making sure you get a nice, lightweight transaction. (This is only beneficial if you are using SQL 2005...Oracle, SQL 2005, etc will automatically be a distributed transaction).

Hi Shakes,

Care to post a patch of your changes for review?

I will as soon as I get a chance but I'm pretty slammed right now and will be for the foreseeable future.