8

I need to be all my entire application transactional in its every web request it processes.

I need the transaction to start and, if there was no exceptions in controllers, commit it. Otherwise, rollback.

So far, I have the following implementation:

  • First, I create transaction on controller as a dependency.
  • Then, I do my controller/service/repositories/other stuff work.
  • And finally, the main abstract controller class executes its OnActionExecuted method, where I either commit it or I don't.

Here goes the list of technologies that I use:

  • MVC 4
  • Ninject
  • Automapper
  • Service pattern

Now, what I want to know is what about the deadlocks? What will happen when two web requests will be simultaneously processed, and besides they will acquire the right to work with two repositories (which are linked to the theirs DataContext instances), and which means, two tables in the database?

For example: one request at first wants to read table Table1 and then Table2, in meantime the other request wants to work with Table2 and then with Table1.

What should I do?

AgentFire
  • 8,944
  • 8
  • 43
  • 90
  • I will answer as a comment, because my answer's scope (and I think your question's) require much more than a SO answer. IMO you need to separate your presentation concerns from your "domain" (or business logic). That architecture gives you two advantages: a) the ability to orchestrate the execution of individual logical subcomponents and their participation (or not) in a MS-controlled transaction,and b) code infrastructure that lends itself much better to implementing some form of custom transaction or queuing,if out-of-the box tools and best-practices aren't enough due to your app's specifics – G. Stoynev May 19 '13 at 20:01

2 Answers2

2

you can handle start and stop of transaction for call to DB please check this

How to prevent EntityFramework deadlock when concurrently running these two statements

hope this help

Community
  • 1
  • 1
zaheer ahmad
  • 294
  • 4
  • 16
  • Yes I can but the main reason I have transferred this option to semi-automatic flow is I dont want to manually each time open and close the transaction. – AgentFire May 14 '13 at 14:15
  • Interesting question, like to see a good answer for this with the provided technologies you use. – Patrick Magee May 15 '13 at 21:05
  • 1
    I love you thinking about this problem. I have gotten some thing like this, and spent a few days to resolving it. The problem because, we need an unit of work for this case, but in EF we already has it in DataContext, so we have to implement the DataContext with implementing IDisposable interface. Then after we wrap it in the context scope like using keyword. and we can release the connection that associate with it after calling completed. – thangchung May 17 '13 at 08:02
0

Okay, I have realized some solutions to the question:

  • The first one is to have a list of all the tables and access them by that list. Thus, the exampled Table2 will never be accessed before Table1 if both are required by the context, and the deadlock will not happen.

  • The second is to create a lazy-IO system which tracks all the necessary changes (like adding an item, retriving its id and using it somewhere else). But it seems quite difficult to build.

  • Another approach is to create application-level locks on every database request at its start and release it at the end. The solution is completely deadlock-free, however it is usable only on low-load systems.

AgentFire
  • 8,944
  • 8
  • 43
  • 90