SqlTransaction not rolling back

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Weird behavior, at least to me, so not sure if this is correct

I have a function in a class that creates a connection object, opens it, creates a sql transaction object for that connection object, and then begins a try-catch block

Inside the try block, four functions are called, and each is passed the transaction object. Each function calls a stored procedure. And so on and so forth. Typical stuff

At the end of the try block, it commits the transaction. Inside the catch, it rollsback. If I put a "throw new Exception" call randomly in the various functions, every thing works as it is supposed to

What isn't typical, that I can tell, is this. If I am stepping through the debugger, and stop the debugger itself, whichever function I am in gets completed, and the transaction is committed

Neither points make sense. If I am in line 3 of a function that doesn't call the stored procedure until line 15, how does line 15 execute if I stop the debugger? And why does the transaction get committed before it ever gets to an explicit trans.Commit() line in the code

Is either expected behavior

TI
jdn
 
Do you have something in the watch window that is calling the sproc or
commiting the transaction?

jdn said:
Weird behavior, at least to me, so not sure if this is correct.

I have a function in a class that creates a connection object, opens it,
Click to expand...
creates a sql transaction object for that connection object, and then begins
a try-catch block.
Inside the try block, four functions are called, and each is passed the
Click to expand...
transaction object. Each function calls a stored procedure. And so on and
so forth. Typical stuff.
At the end of the try block, it commits the transaction. Inside the
Click to expand...
catch, it rollsback. If I put a "throw new Exception" call randomly in the
various functions, every thing works as it is supposed to.
What isn't typical, that I can tell, is this. If I am stepping through
Click to expand...
the debugger, and stop the debugger itself, whichever function I am in gets
completed, and the transaction is committed.
Neither points make sense. If I am in line 3 of a function that doesn't
Click to expand...
call the stored procedure until line 15, how does line 15 execute if I stop
the debugger? And why does the transaction get committed before it ever
gets to an explicit trans.Commit() line in the code?
 
No. It looks like the entire 'master function' (the one that calls the individual 4 functions) completes its execution no matter what when the debugger is stopped. So, if I put in a "trans.Rollback()" at the very end, it rolls it back, if not, it hits the Commit() at the very end and commits. Even if I stop it when it is at the beginning of function 3, it rolls through the rest of fuction 3, all of function 4, and finishes

jd


----- Marina wrote: ----

Do you have something in the watch window that is calling the sproc o
commiting the transaction

jdn said:
Weird behavior, at least to me, so not sure if this is correct
Click to expand...
creates a sql transaction object for that connection object, and then begin
a try-catch blocktransaction object. Each function calls a stored procedure. And so on an
so forth. Typical stuffcatch, it rollsback. If I put a "throw new Exception" call randomly in th
various functions, every thing works as it is supposed tothe debugger, and stop the debugger itself, whichever function I am in get
completed, and the transaction is committedcall the stored procedure until line 15, how does line 15 execute if I sto
the debugger? And why does the transaction get committed before it eve
gets to an explicit trans.Commit() line in the code
 
Hi jdn,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that transaction is not rolled back, if you
stopped debugging before the transaction was committed. If there is any
misunderstanding, please feel free to let me know.

Could you please let me know what kind of project are you working on? I
assume that you are developing on an ASP.NET project. Because based on my
research, in ASP.NET, this is a known issue. As the abort is not guaranteed
to be synchronous, and you are checking the transaction during the actual
abort. It means that the rollback has been issued to the distributed
transaction controller, but the abort does not wait for the controller to
complete the abort with the various servers.

This is behaviour only occurs in debug mode. You can put the command in a
try catch block. If the a command in the transaction fail, you can ensure
to rollback the transaction in the catch block.

HTH. If anything is unclear, please feel free to reply to the post.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Hello,

This behavior is a known issue and only occur in debug mode. If you don't
want the transaction continue, you run iisreset first and then, stop the
debug.

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Back
Top