TransactionScope strange behavior
Joined: 24-Dec-2009
Joined: 08-Oct-2008
Joined: 24-Dec-2009
MTrinder wrote:
Does it work successfully if you do use a seperate adapter instance for each transaction
Not exactly that but I did try using separate adapters for each of the 4 calls to the database, and that gave the same exact error. The only difference I noticed when I did it that way was the InSystemTransaction flag was marked as true for each adapter, unlike when I used a single adapter for all. Same end result in both cases though 
So you're saying I should use one adapter for the first 2 statements inside txn, then dispose it and create a new one to be used for the second 2 statements in txn2? I can try that but should it really make a difference since it did not even work when I used 4 separate adapters?
Joined: 24-Dec-2009
Joined: 24-Dec-2009
Joined: 24-Dec-2009
Joined: 24-Dec-2009
Joined: 24-Dec-2009
Joined: 08-Oct-2008
since my transaction may span several methods within several classes.
This statement made me think that perhaps you do need to reconsider the design of your application...
IMO, all you should be doing between starting and committing a transaction is saving objects to the database, if you are having to call out to other classes and methods you are holding the transaction open for longer than you need to, which is generally considered a "bad thing"
What are you actually doing in these other class and method calls - do they actually NEED to be in the transaction...?
Matt
Joined: 24-Dec-2009
pt wrote:
Frans,
Thanks for the response and explanation of how things work. Just to be clear in case my intention was not, my goal isn't to figure out how to get MSDTC working, it's how to get transactionscopes working without involving MSDTC unless absolutely necessary. I'd rather not deal with the configuration and firewalls and performance overhead of MSDTC when all my operations are performed on a single database so there should be no need to go to that level if I set things up properly.
Distributed transactions always use DTC if I'm not mistaken. Anyway, that's not the issue here ->
Otis wrote:
when a transaction is started on the adapter, it actually doesn't start an ADO.NET transaction, it simply notes that one is in progress.
Doesn't this require the transactionscope to be created before the adapter is though? Where I'm running into a problem is that my singleton adapter gets created on the page Init but I may not create a TS until later in the page when I am executing some database operations. So the existing adapter does not seem to recognize it is inside a TS (i.e. InSystemTransaction reports false). That's why I was thinking I would need to force the adapter to check if there is a current system transaction in existence and if so then call EnlistTransaction on its own connection method. Do you think that would work and if so how would I get at the adapter's active connection object?
That's indeed the requirement: The TS has to be there, before the adapter is created (so it can enlist itself).
Doing that manually will be messy, I wouldn't go there. It's also not necessary, as all actions are done on the same DB, you share the adapter, so just use an ado.net transaction using adapter.BeginTransaction() and adapter.Commit(). But there's a better alternative: UnitOfWork2 If you want work done in a single transaction, and you have to collect work in multiple parts of your code base, create a UnitOfWork2 object, and add the work to that object and pass that around.
When you're done, simply commit it using an adapter, it will be done in a single transaction which you can auto-commit. The transaction won't use DTC. Downside is that you can't do fetching with the unitofwork. But as there's no transaction in progress on the current thread, it's ok to create an adapter in a sub method somewhere along the way and fetch some data.
Keep an eye on singleton's / other sharing objects which share adapters and other objects like unit of work, entities: these objects aren't thread safe.
Otis wrote:
A single connection to SQL Server will likely use a lightweight distributed transaction, as soon as you issue 2 connections, it will create a full distributed transaction. This can for example be triggered from the debugger, or when you issue multiple adapters inside the same distributed transaction. So sharing the adapter, with the connection open across classes (in the same thread!) can help keep the connection from becoming a full distributed transaction.
Yes that's exactly what I'm trying to do, open a connection right when the adapter is initialized at the start of the page and set it to keepConnectionOpen. Then on Page_Unload as suggested above, I would close the connection and dispose the adapter. This way a single connection would be used throughout the entire page. Any downsides you can see to this?
Yes, that's too inefficient. You want to collect work, then quickly open a connection, do the work, and close it again. See above, a unit of work is much easier for this (and designed for this purpose )
Otis wrote:
Question: if you share the adapter anyway, why not use a normal ado.net transaction?
I had started out that way but I ended up running into a few issues. * Sometimes I did not or could not use the singleton adapter for whatever reason (maybe this is indicative of a design flaw) but in any event if I can't 100% be sure it will always be the same adapter then the ado.net route seems to not be an option. * There were often situations where I needed to know at what point in the call stack to issue the commit, since my transaction may span several methods within several classes. The same method may at times be called within a transaction and other times not be, so it's became tough to know when to commit it and when not. * Also with the ado.net adapter, the manual says best practice is to use a try..catch..finally and dispose the adapter in the finally block. But if I'm using a shared adapter, won't that pose a problem if there are additional actions to perform on that page after the failed transaction?
adapters are cheap, they're created instantly. Therefore, don't keep them around, unless you need to (e.g. pass it around for transaction sharing). As unit of work is also usable for that (collecting work to be persisted in a single transaction) I'd go that route.
pt wrote:
MTrinder wrote:
What are you actually doing in these other class and method calls - do they actually NEED to be in the transaction...?
I guess an example would be saving a user's signup information. You may have a UserManager class that saves the contact information, an AuthManager class that saves the login credentials, and several others that populate related database tables as necessary to create the data needed for a new user in the system. They all need to work as a unit (otherwise the data may go out of sync) but all the methods may be in different classes in the business layer because they operate on different entities. Seems to be a fairly basic setup to me, nothing majorly complicated.
A very simplified example would be something like the below (ignore the syntax).
class ProcessSignup { //ths is where transaction would start UserManager.AddUser(u) AuthManager.AddLogin(u) //....etc //end transaction } class UserManager{ function AddUser(u){ UserRepository.Add(u) //...other operations here } } class AuthManager{ function AddLogin(u){ LoginRepository.Add(u) //...other operations here } }So the transaction needs to surround the whole ProcessSignup operation because it needs to either succeed or fail as a unit. (This, by the way, is another conceptual problem I have with the idea of using ADO transactions because it feels like bad design to have the business layer starting a transaction on the adapter that resides in the data layer.) Hope that all makes sense.
This is ideal for a unitofwork. Simply pass it along with the methods which create data. Add the entities to the unitofwork and in the end, persist it with a single call by doing:
using(var adapter = new DataAccessAdapter())
{
myUnitOfWork.Commit(adapter, true);
}
Joined: 24-Dec-2009
Otis wrote:
This is ideal for a unitofwork. Simply pass it along with the methods which create data.
Well that was my original approach, using UoW and passing it everywhere, but I quickly began to feel like this guy for the reasons I mentioned above.
The biggest issue is how to know at what point I'm at the outermost transaction in order to do the commit? i.e. there may be times in method A where it should commit inside that method, but other times it may be part of a bigger transaction and therefore should not commit yet. I realize that could just indicate the method is doing too much and should be broken out into a few smaller pieces, but I don't know if it's as simple as that because otherwise I would have gone that route originally instead of seeking out alternatives.
Other primary issue, which is more of an aesthetic one I suppose, is that adding an additional parameter to every method that saves data just feels inelegant and unnecessary, not to mention the refactoring involved. Would it be possible/wise/threadsafe to implement a shared UoW, maybe stored in HttpContext as I was doing with the adapter? Then the methods could automatically add themselves to that without it having to be passed around?
FWIW I found this thread which echoes exactly what I'm talking about, same suggested solution though. Is there no better solution 3 years later? http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=13620&StartAtMessage=0𒠸
pt wrote:
Otis wrote:
This is ideal for a unitofwork. Simply pass it along with the methods which create data.
Well that was my original approach, using UoW and passing it everywhere, but I quickly began to feel like this guy
UOW is ideal for your scenario. IMHO, your should know when it has to commit.
pt wrote:
The biggest issue is how to know at what point I'm at the outermost transaction in order to do the commit? i.e. there may be times in method A where it should commit inside that method, but other times it may be part of a bigger transaction and therefore should not commit yet. I realize that could just indicate the method is doing too much and should be broken out into a few smaller pieces, but I don't know if it's as simple as that because otherwise I would have gone that route originally instead of seeking out alternatives.
As I said above, your code should know when it finally has to commit. To overcome the situation you mentioned, you could create simply method overloads. Example:
public void SaveCustomer(CustomerEntity customerToSave)
{...}
public void SaveCustomer(CustomerEntity customerToSave, UnitOfWork uowToUse)
{...}
Then use it in a higher level
UnitOfWork uow = new UnitOfWork(..);
// add the call to uow
CustomerBL.SaveCustomer(theCustomer, uow);
// add other calls
...
uow.Commit();
// just save the customer and forget it
CustomerBL.SaveCustomer(theCustomer);
pt wrote:
Other primary issue, which is more of an aesthetic one I suppose, is that adding an additional parameter to every method that saves data just feels inelegant and unnecessary, not to mention the refactoring involved. Would it be possible/wise/threadsafe to implement a shared UoW, maybe stored in HttpContext as I was doing with the adapter? Then the methods could automatically add themselves to that without it having to be passed around?
Sure you can do that. You will face the same question though: "When should I commit?", but if that is clear to you, you can do that. Doing this is less problematic than keep a DAA in the thread.
pt wrote:
FWIW I found this thread which echoes exactly what I'm talking about, same suggested solution though. Is there no better solution 3 years later? http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=13620&StartAtMessage=0𒠸
Well, the features are there: UnitOfWork, DataAccessAdapter, native Transactions, TransactionScopes. I can't think a thing you cannot do with that. Also there are many patterns out there you can refer to know what is the best approach to you.