Thread Abort --> close connection

  • Thread starter Thread starter LP
  • Start date Start date
L

LP

Hi,

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

workerThread.Abort();

ThreadAbort Exception is handeled in the worker thread:

catch (System.Threading.ThreadAbortException ex)

{

//thread aborted send this message to the client

OnProcessAbort(new WorkerProcessBalanceEventArgs(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 dont know of your specific case but I am certain you dont want to call
Thread.Abort. It has side effects because thread does not get a chance to
clean up. Instead of calling Abort, can you periodically look and see if an
event has been signalled and then exit the thread gracefully at that point?
 
LP said:
I am starting a new thread from the main UI thread. If users clicks cancel
button, the thread is aborted:

workerThread.Abort();
Click to expand...

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.Threading.ThreadAbortException ex)

{

//thread aborted send this message to the client

OnProcessAbort(new WorkerProcessBalanceEventArgs(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.
Click to expand...

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.
Click to expand...

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

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.
 
LP said:
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.
Click to expand...

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.
Click to expand...

Right - that's a much better way of operating.
 
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.
Click to expand...

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.
 
LP said:
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.
Click to expand...

Well, the .NET client should still be connected - I don't know why it
would normally log out, unless your data layer is deliberately closing
the physical connection (which means you're not using connection
pooling).

I know you're not in control of the real data layer, but I'd try to
knock up a test program to see what makes it log out and when.
 
Back
Top