Thread Abort --> close connection

Hi,

I am starting a new thread from the main UI thread. If users clicks cancel
button, the thread is aborted:

workerThread.Ab ort();

ThreadAbort Exception is handeled in the worker thread:

catch (System.Threadi ng.ThreadAbortE xception ex)

{

//thread aborted send this message to the client

OnProcessAbort( new WorkerProcessBa lanceEventArgs( ex.Message, 0, 0, false));
}

Everything seems to work. But I am noticing in SQL Profiler that it doesn't logout active connection as it usually does if I let this thread just run
through. Keep in mind that conection object is not visiable to worker thead. Worker thread creates another object written by other group of developers
that does all db related work. At this time I can not modify db related
class, because they're working on the new release, so my changes will be
lost.

Is there a way to close all open connections within appDomain when worker
thread is aborted? Thank you.

I am starting a new thread from the main UI thread. If users clicks cancel
button, the thread is aborted:

workerThread.Ab ort();
As Ajay says, that's not a terribly good idea - see
http://ww.pobox.com/~skeet/csharp/threads/abort.shtml
ThreadAbort Exception is handeled in the worker thread:

catch (System.Threadi ng.ThreadAbortE xception ex)

{

//thread aborted send this message to the client

OnProcessAbort( new WorkerProcessBa lanceEventArgs( ex.Message, 0, 0, false));

}

Everything seems to work. But I am noticing in SQL Profiler that it doesn't
logout active connection as it usually does if I let this thread just run
through. Keep in mind that conection object is not visiable to worker thead.
Worker thread creates another object written by other group of developers
that does all db related work. At this time I can not modify db related
class, because they're working on the new release, so my changes will be
lost.
It sounds like you don't have an appropriate finally block doing the
clean-up. Note that even though you caught the exception, it will still
be propagated after OnProcessAbort has completed.
Is there a way to close all open connections within appDomain when worker
thread is aborted? Thank you.

finally blocks to clean things up.
Jon,

The problem is that I don't have access to the reference of connection
object that lives inside another class. I am using a data access assembly
developed by another group. Even though I do have access to the source code,
I can't modify. They do use -- using(sqlConn){//code here} , so
theoretically the connection should be disposed if any Exception are
thrown. But apparently it does not get disposed.
I am going to look into singanling the thread when cancel is attempted. And
let it finish running db assembly - whatever it's doing there, and then exit
the thread. So when cancel button is clicked it wont run the next database
related work step in the process, rather then brutally aborting the current
one without giving it a chance to clean up.

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... LP <lp@a.com> wrote:

I am starting a new thread from the main UI thread. If users clicks cancel button, the thread is aborted:

workerThread.Ab ort();

As Ajay says, that's not a terribly good idea - see
http://ww.pobox.com/~skeet/csharp/threads/abort.shtml

ThreadAbort Exception is handeled in the worker thread:

catch (System.Threadi ng.ThreadAbortE xception ex)

{

//thread aborted send this message to the client

OnProcessAbort( new WorkerProcessBa lanceEventArgs( ex.Message, 0, 0, false));
}

Everything seems to work. But I am noticing in SQL Profiler that it doesn't logout active connection as it usually does if I let this thread just run through. Keep in mind that conection object is not visiable to worker thead. Worker thread creates another object written by other group of developers that does all db related work. At this time I can not modify db related
class, because they're working on the new release, so my changes will be
lost.

It sounds like you don't have an appropriate finally block doing the
clean-up. Note that even though you caught the exception, it will still
be propagated after OnProcessAbort has completed.

Is there a way to close all open connections within appDomain when worker thread is aborted? Thank you.

Not as such - instead, you need to write your code with appropriate
finally blocks to clean things up.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Not as such - instead, you need to write your code with appropriate
finally blocks to clean things up.
The problem is that I don't have access to the reference of connection
object that lives inside another class. I am using a data access assembly
developed by another group. Even though I do have access to the source code,
I can't modify. They do use -- using(sqlConn){//code here} , so
theoretically the connection should be disposed if any Exception are
thrown. But apparently it does not get disposed.

How sure are you that it's not being disposed? Bear in mind that the
physical connection wouldn't be closed - it would just return it to the
pool.
I am going to look into singanling the thread when cancel is attempted. And
let it finish running db assembly - whatever it's doing there, and then exit
the thread. So when cancel button is clicked it wont run the next database
related work step in the process, rather then brutally aborting the current
one without giving it a chance to clean up.

physical connection wouldn't be closed - it would just return it to the
pool.
Well, I am running a SQL Profiler trace; usually when thread finishes its
work, I can see ".NET client logout" message in a profiler. However when
thread is aborted I don't see that , also sp_who shows that .NET client is
still actively connected.
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com... LP <lp@a.com> wrote:

Not as such - instead, you need to write your code with appropriate
finally blocks to clean things up.

The problem is that I don't have access to the reference of connection
object that lives inside another class. I am using a data access assembly developed by another group. Even though I do have access to the source code, I can't modify. They do use -- using(sqlConn){//code here} , so
theoretically the connection should be disposed if any Exception are
thrown. But apparently it does not get disposed.

How sure are you that it's not being disposed? Bear in mind that the
physical connection wouldn't be closed - it would just return it to the
pool.

I am going to look into singanling the thread when cancel is attempted. And let it finish running db assembly - whatever it's doing there, and then exit the thread. So when cancel button is clicked it wont run the next database related work step in the process, rather then brutally aborting the current one without giving it a chance to clean up.

Right - that's a much better way of operating.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

How sure are you that it's not being disposed? Bear in mind that the
physical connection wouldn't be closed - it would just return it to the
pool.

Well, I am running a SQL Profiler trace; usually when thread finishes its
work, I can see ".NET client logout" message in a profiler. However when
thread is aborted I don't see that , also sp_who shows that .NET client is
still actively connected.