Hi all,

.NET's TransactionScope suppports "voting" basically if there are nested Transactionscopes all have to be true before the transaction is comitted.

Does LLBLGen's Adapter.StartTransaction support something similar?

For example:

Public Sub DeleteEntity()
     CreateAdapter
     Adapter.Starttransaction
     DeleteEntityA()
     DeleteEntityB()
     Adapter.Committ
End Sub

Public Sub DeleteEntityA()
    'CreateAdapter
    'StartTransaction
    'Do Stuff
    'Commit
End Sub

Public Sub DeleteEntityB()
    'CreateAdapter
    'StartTransaction
    'Do Stuff
    'Commit
End Sub

Will both functions be committed only if A & B are successful?

I'm using LLBLGen 2.5, April 23rd release with SQL Server 2000.

Thanks.

No, no with ADO.NET transactions, however you can use .NET 2.0 System.Transactions with LLBLGen Pro .NET 2.0 System.Transactions support. Note that this requires support by the used database system as the database system has to be able to promote a non-distributed transaction to a distributed transaction. When .NET 2.0 shipped, only SqlServer 2005 was able to promote transactions to distributed transactions using System.Transactions' classes.

What you can do also is: pass the _DataAccessAdapter _object into _DeleteEntityA _and _DeleteEntityB _and use it inside those methods, then commit the whole transaction at _DeleteEntity _method.

Hi Daelmo,

That's what I thought I had to do - however, passing the adapter around seems inelegant as it requires code to have knowledge that it is being called by an outside transaction.

With System.Transactions I can just recursively call nested functions and not worry about an "adapter".

However, the drawback is obviously System.Transactions only works with SQL 2005...

Any plans to add something like System.Transactions into LLBLGen's framework? I did a quick search of the forums and I think there have been others requesting something similar?

however, passing the adapter around seems inelegant as it requires code to have knowledge that it is being called by an outside transaction.

Use a UnitOfWork and pass it around instead of the adapter, that's exactly what the UoW was made for.

Walaa wrote:

however, passing the adapter around seems inelegant as it requires code to have knowledge that it is being called by an outside transaction.

Use a UnitOfWork and pass it around instead of the adapter, that's exactly what the UoW was made for.

I looked at the UoW, but the issue with it is that I need to track when I've bubbled all the way up before committing the data. Basically the framework doesn't provide the ability to determine the scope of the call and commit appropriately only when I reached the top level of the call stack.

I'll resort to passing the adapter around and refactor the code.

mshe,

You might want to check out the latest 2 part video on dnrTV, which talked about the TransactionScope and how to create your own scope classes. http://www.dnrtv.com/default.aspx?showNum=113 http://www.dnrtv.com/default.aspx?showNum=114

You might be able to create your own scope and call it LLBLTransactionScope and not go the route of passing around the Adapter.

taylor74 wrote:

mshe,

You might want to check out the latest 2 part video on dnrTV, which talked about the TransactionScope and how to create your own scope classes. http://www.dnrtv.com/default.aspx?showNum=113 http://www.dnrtv.com/default.aspx?showNum=114

You might be able to create your own scope and call it LLBLTransactionScope and not go the route of passing around the Adapter.

Thank you, that's a great idea