MattHoneycutt / Fail-Tracker

Fail Tracker is an agile issue tracking system written with ASP.NET MVC.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question with Transaction Per Request

JalpeshVadgama opened this issue · comments

Hello Matt,

You have done great job for building this framework. I have one question related to Transaction Per Request pattern here.

We have implemented the same thing in our project which you have used in FailTracker. Our project is like where hundred users will be online at same time.

We have mostly select queries and some time update queries so lets say there is a request which contains 10 select queries and 1 insert queries in tables.

From our analysis we have found that If we go with this way. It is having same transaction for all the queries whether select or insert. Don't you think select queries should not be part of transaction as if you have hundred of users same time at that time it blocking one user till all select and insert queries completes or fail.

Do you think is there a way to overcome this? Because mostly we have found that in our application our users are browsing site and insert queries will very less our ratios are you will have 1 Insert or update queries against 10 select queries.

Do you think we could address this problem with better way. Any help would be appreciated.

Thanks again for great framework.

As long as you are using the default isolation level, the transaction won't block reads unless they touch a row that has an active write operation against it. That means you can have as many active requests doing reads as you want, and they won't block each other.

Requests should be fast enough that even a request involving a write won't cause a noticeable performance impact on other requests. If they're not, then you should optimize things anyway. Your writes shouldn't typically escalate to a table lock, but if that's happening often, then again, you may need to do some tuning.

If for some reason you do have a heavier percent of writes, then you may want to reduce the isolation level on the transaction. That will allow reads to proceed without blocking, but could result in them seeing uncommitted data.

Keep in mind, with EF, if you don't explicitly create a transaction, one is implicitly created for you when you call SaveChanges. Your reads will also still be subject to the standard locking policies since the default isolation level is 'read committed.'

Thanks for your time. I will check and ask questions if anything.