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. 6 10552
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.
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
> 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
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
> 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
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 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
|
6 posts
views
Thread by Joe HM |
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
| | | | | | | | | | |