Multithreading and RollBacks

  • Thread starter Thread starter wdewebserver
  • Start date Start date
W

wdewebserver

Hi

I have a multi-threaded application that is of Parent-Child relation. For
example App1 will run and on completion fire App1.1, App1.2 and App1.3 which
can run in parallel. App2 depends on the successful completion of the last
three. If App2 fails or any of the three, I want the whole thing to
rollback.
How can I accomplished the rollback in multi-threading environment? Each App
writes to the db.

regards
walterd
 
Are App1, App1.1, App1.2, App1.3 and App2 separate processes or multiple functions on separate threads or a combination of both?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi

I have a multi-threaded application that is of Parent-Child relation. For
example App1 will run and on completion fire App1.1, App1.2 and App1.3 which
can run in parallel. App2 depends on the successful completion of the last
three. If App2 fails or any of the three, I want the whole thing to
rollback.
How can I accomplished the rollback in multi-threading environment? Each App
writes to the db.

regards
walterd
 
App1.1, App1.3 and App1.3 are all running on different threads. App1, on
completion, will trigger the three job


Richard Blewett said:
Are App1, App1.1, App1.2, App1.3 and App2 separate processes or multiple
Click to expand...
functions on separate threads or a combination of both?
 
OK, after some investigation (of trying to bend various framework subsystems to my will) I think you're only left with one solution.

You cannot run multiple commands over the same connection and so over the same local transaction as ADO.NET 1.1 doesn't support multiple active resultsets

You cannot run mutliple concurrent database requests under the same global stransaction as the context bound nature of a serviced component will force all of these requests into the same COM+ Activity and so will get serialized.

I think you are going to have to use the concept of a compensating transaction. In other words, keep a track of what work has been performed by App1.1, App1.2, App1.3 and then if there is a problem in any of those, or there is a problem in App2, issue new commands to revert to the old state. Is this foolproof? no its damn hard because you have to worry about other transactions that may have changed data in the meantime.

To be frank, you are better of letting the updates happen sequentially

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

App1.1, App1.3 and App1.3 are all running on different threads. App1, on
completion, will trigger the three job
 
When work is split between applications it is same as if work is split
between different people. Army as organization is trying to make groups of
people work as inside transaction. You know the results.

Behavior of applications in systems controlled by user(s) is unpredictable
by definition. Hence the impossibility to transact / rollback.

I like the question, because it addresses primary problem of how you can
create predictably behaving system in unpredictable circumstances. I think
the whole approach is politically incorrect. When you delegate part of work
(trimming) to somebody else (barber) you can't predict the results (will you
be bald or just pathetic afterwards). Same with apps. At the same time you
can always see if milkman did his/her job all right. So, next step, like
feeding the cat, depends on the result of previous one. If your apps behave
in same way - never believe the results of previous step are Ok and check
every required detail - you will be safe. And maybe even your system. If
milkman delivers sour milk, do you feed your cat with it or fresh fish if
you have any? Do you need rollback in this situation? You might want it but
will never get it.
HTH
Alex

Richard Blewett said:
OK, after some investigation (of trying to bend various framework
Click to expand...
subsystems to my will) I think you're only left with one solution.
You cannot run multiple commands over the same connection and so over the
Click to expand...
same local transaction as ADO.NET 1.1 doesn't support multiple active
resultsets
You cannot run mutliple concurrent database requests under the same
Click to expand...
global stransaction as the context bound nature of a serviced component will
force all of these requests into the same COM+ Activity and so will get
serialized.
I think you are going to have to use the concept of a compensating
Click to expand...
transaction. In other words, keep a track of what work has been performed by
App1.1, App1.2, App1.3 and then if there is a problem in any of those, or
there is a problem in App2, issue new commands to revert to the old state.
Is this foolproof? no its damn hard because you have to worry about other
transactions that may have changed data in the meantime.
 
Back
Top