468,140 Members | 1,435 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,140 developers. It's quick & easy.

Thread Abort --> close connection

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.
Nov 16 '05 #1
6 10438
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?

--
Ajay Kalra [MVP - VC++]
aj*******@yahoo.com
"LP" <lp@a.com> wrote in message
news:us**************@TK2MSFTNGP12.phx.gbl...
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.

Nov 16 '05 #2
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.Abort();
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.
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #3
LP
> Not as such - instead, you need to write your code with appropriate
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.com> wrote in message
news:MP************************@msnews.microsoft.c om... 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.Abort();


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.


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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #4
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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #5
LP
> 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.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m... 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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #6
LP <lp@a.com> wrote:
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.


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Bill | last post: by
20 posts views Thread by Doug Thews | last post: by
18 posts views Thread by Urs Vogel | last post: by
5 posts views Thread by andrew | last post: by
6 posts views Thread by mehdi | last post: by
7 posts views Thread by =?Utf-8?B?R2lkaQ==?= | last post: by
4 posts views Thread by raghudr | last post: by
27 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.