<p>I'm writing a pretty straightforward <code>e-commerce app</code> in <strong>asp.net</strong>, do I need to use transactions in my stored procedures?</p>

<p>Read/Write ratio is about 9:1</p>

[{'answer_id': 60423, 'author': 'Codeslayer', 'author_id': 4021, 'author_profile': 'https://Stackoverflow.com/users/4021', 'pm_score': 4, 'selected': True, 'text': '<p>Many people ask - do I need transactions? Why do I need them? When to use them?</p>\n\n<p>The answer is simple: use them all the time, unless you have a very good reason not to (for instance, don\'t use atomic transactions for "long running activities" between businesses). The default should always be yes. You are in doubt? - use transactions.</p>\n\n<p>Why are transactions beneficial? They help you deal with crashes, failures, data consistency, error handling, they help you write simpler code etc. And the list of benefits will continue to grow with time.</p>\n\n<p>Here is some more info from <a href="http://blogs.msdn.com/florinlazar/" rel="nofollow noreferrer">http://blogs.msdn.com/florinlazar/</a></p>\n'}, {'answer_id': 60428, 'author': 'Till', 'author_id': 2859, 'author_profile': 'https://Stackoverflow.com/users/2859', 'pm_score': 1, 'selected': False, 'text': "<p>The answer is, it depends. You do not always need transaction safety. Sometimes it's overkill. Sometimes it's not.</p>\n\n<p>I can see that, for example, when you implement a checkout process you only want to finalize it once you gathered all data, etc.. Think about a payment f'up, you can rollback - that's an example when you need a transaction. Or maybe when it's wise to use them.</p>\n\n<p>Do you need a transaction when you create a new user account? Maybe, if it's across 10 tables (for whatever reason), if it's just a single table then probably not.</p>\n\n<p>It also depends on what you sold your client on and who they are, and if they requested it, etc.. But if making a decision is up to you, then I'd say, choose wisely. </p>\n\n<p>My bottom line is, avoid premature optimization. Build your application, keep in mind that you may want to go back and refactor/optimize later when you need it. Look at a couple opensource projects and see how they implemented different parts of their app, learn from that. You'll see that most of them don't use transactions at all, yet there are huge online stores that use them.</p>\n"}, {'answer_id': 60443, 'author': 'Danny Whitt', 'author_id': 375, 'author_profile': 'https://Stackoverflow.com/users/375', 'pm_score': 1, 'selected': False, 'text': '<p>Of course, it depends.</p>\n\n<p>It depends upon the work that the particular stored procedure performs and, perhaps, not so much the "read/write ratio" that you suggest.  In general, you should consider enclosing a unit of work within a transaction if it is query that could be impacted by some other, simultaneously running query.  If this sounds nondeterministic, it is.  It is often difficult to predict under what circumstances a particular unit of work qualifies as a candidate for this.</p>\n\n<p>A good place to start is to review the precise <a href="http://en.wikipedia.org/wiki/Create,_read,_update_and_delete" rel="nofollow noreferrer">CRUD</a> being performed within the unit of work, in this case within your stored procedure, and decide if it a) could be affected by some other, simultaneous operation and b) if that other work matters to the end result of this work being performed (or, even, vice versa).  If the answer is "Yes" to both of these then consider wrapping the unit of work within a transaction.</p>\n\n<p>What this is suggesting is that you can\'t always simply decide to either <em>use or not use transaction</em>s, rather you should apply them when it makes sense.  Use the properties defined by <a href="http://en.wikipedia.org/wiki/ACID" rel="nofollow noreferrer">ACID</a> (Atomicity, Consistency, Isolation, and Durability) to help decide when this might be the case.</p>\n\n<p>One other thing to consider is that in some circumstances, particularly if the system must perform many operations in quick succession, e.g., a high-volume transaction processing application, you might need to weigh the relative performance cost of the transaction.  Depending upon the size of the unit of work, a commit (or rollback) of a transaction can be resource expensive, perhaps negatively impacting the performance of your system unnecessarily or, at least, with limited benefit.</p>\n\n<p>Unfortunately, this is not an easy question to precisely answer: "It depends."</p>\n'}, {'answer_id': 60647, 'author': 'Mike L', 'author_id': 4796, 'author_profile': 'https://Stackoverflow.com/users/4796', 'pm_score': 2, 'selected': False, 'text': '<p>Remember in SQL Server all single statement CRUD operations are in an implicit transaction by default.  You just need to turn on explict transactions (BEGIN TRAN) if you need to make multiple statements act as an atomic unit.</p>\n'}, {'answer_id': 62551, 'author': 'David T. Macknet', 'author_id': 6850, 'author_profile': 'https://Stackoverflow.com/users/6850', 'pm_score': 0, 'selected': False, 'text': "<p>Use them if:</p>\n\n<ol>\n<li>There are some errors that you may want to test for and catch which won't be caught except by you going out and doing the work (looking things up, testing values, etc.), usually from within a transaction so that you can roll back the whole operation.</li>\n<li>There are multi-step operations of any sort, which should, logically, be rolled back as a group if they fail.</li>\n</ol>\n"}]
['https://Stackoverflow.com/questions/60419', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3661/']