auto-commit vs begin transaction overhead

I've googled for the answer and searched sql server 2005 books online and I haven't been able to find the answer to my question. My main question is what is the difference in overhead between using auto-commit on every statement or explicitly calling begin transaction on every statement. I'm basically looking for documentation that points to the difference. Read on for the scenario...

We have an application that has problems with deadlocks. Part of our strategy in handling these deadlocks is resubmitting the transaction. My solution to this part of the strategy is to wrap every storedprocedure in a transaction so this would include reads and writes. My architect has raised some concerns with regard to performance if it's implemented this way. I've come across documentation (http://msdn2.microsoft.com/en-us/library/ms187878.aspx) in the sql server 2005 books online that auto-commit happens on every statement anyway but haven't come across anything that explicitly states the performance penalty if there is one. Is there difference in overhead between calling 'BeginTransaction' for every statement or just letting auto-commit do it's magic. Is this implemented in SqlClient object or at a database level?Some folks from the database engine team would be best suited to answer your question re: auto-commit vs. explicit transaction performance. Depending on their answer, you might also want to follow up with folks in the .Net Data Access and Storage forum to ensure there are no performance implications in the particular client that you are using.|||

AFAIK, definetely there is an overhead. And how much overhead depends on the traffic on your application, and the size of the DB.

There will be lot of contention since transactions will keep the locks until the transaction commits. You might see slow down in your transaction times. If you have a web form and a submit button, you keep the user waiting longer for his transaction to commit if there are more transactions waiting. Also, there could be timeout issues. Your CPU could shoot up. If you use #temp tables your tempDB could blow up.

If you have dead lock scenarios I would look into which procs cause it and fix them rather than wrap every T-SQL with a transaction.

And if you really want to measure the overhead, you can use some 3rd party tools like NetIQ and do a load test and quantify the results.