ContextSwitchDe adlock

[OldButStillLearning]

Hello, I am getting this "ContextSwitchD eadlock" error message pop up in
situations where I am doing a Data Reader loop, where I am processing about
40,000 records. For each record read via the data reader, I am creating
another data reader to read another database table (can't join these tables -
on different machines) to get additional information. I am guessing that I
am getting this error message becuase the loop is taking longer the 60
seconds to complete. Here is what is said about the error
"The most probable cause is that a single-threaded apartment (STA) thread is
not pumping messages. The STA thread is either waiting without pumping
messages or is performing lengthy operations and is not allowing the message
queue to pump."

I'm sorry, but I do not have a clue as to what this means. The other
probable cause is a process is consuming too much memory. Not sure That this
would apply to me but perhaps opening and closing 40,000 data readers is
sucking up memory, although I would have expected the garbage collector to
have released this memory, but perhpas because it is all within the same
paragraph, the memory is not being release. I often just cancel out of the
error message and continue with the process and it completes successfully, so
I don't think it is a memory issue.
If I do not run in debug mode, I get the same error message running in
"Release" mode.

I read that you can turn off the MDA errors via the config file, but this
does not seem to me to be the appropriate solution to the problem... Does it?

Any ideas or suggestions?

Thanks in advance for your assistance!!!!

[Peter Bromberg [C# MVP]]

OldButStillLear ning,
When you opine "can't join these tables - on different machines" are you
saying you can't have a SQL Statement that joins a table on a database in
another server?
You should be able to do this with SQL Server.
It could save you a lot of pain.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"OldButStillLea rning" wrote:

Hello, I am getting this "ContextSwitchD eadlock" error message pop up in
situations where I am doing a Data Reader loop, where I am processing about
40,000 records. For each record read via the data reader, I am creating
another data reader to read another database table (can't join these tables -
on different machines) to get additional information. I am guessing that I
am getting this error message becuase the loop is taking longer the 60
seconds to complete. Here is what is said about the error
"The most probable cause is that a single-threaded apartment (STA) thread is
not pumping messages. The STA thread is either waiting without pumping
messages or is performing lengthy operations and is not allowing the message
queue to pump."

I'm sorry, but I do not have a clue as to what this means. The other
probable cause is a process is consuming too much memory. Not sure That this
would apply to me but perhaps opening and closing 40,000 data readers is
sucking up memory, although I would have expected the garbage collector to
have released this memory, but perhpas because it is all within the same
paragraph, the memory is not being release. I often just cancel out of the
error message and continue with the process and it completes successfully, so
I don't think it is a memory issue.
If I do not run in debug mode, I get the same error message running in
"Release" mode.

I read that you can turn off the MDA errors via the config file, but this
does not seem to me to be the appropriate solution to the problem... Does it?

Any ideas or suggestions?

Thanks in advance for your assistance!!!!

[Andy]

First, I'm assuming you hve a UI running?

If you can't do as Peter suggests, you may want to try running this
process in its own thread.

[Willy Denoyette [MVP]]

If you run this on a UI thread, you should move this task to an auxiliary
thread, the task blocks the pump for too long (that's why you see the MDA in
debug mode).
If it's not a UI thread, you should not initialize the thread as an STA
thread.

Willy.

"OldButStillLea rning" <Ol************ *****@discussio ns.microsoft.co m> wrote
in message news:28******** *************** ***********@mic rosoft.com...
| Hello, I am getting this "ContextSwitchD eadlock" error message pop up in
| situations where I am doing a Data Reader loop, where I am processing
about
| 40,000 records. For each record read via the data reader, I am creating
| another data reader to read another database table (can't join these
tables -
| on different machines) to get additional information. I am guessing that
I
| am getting this error message becuase the loop is taking longer the 60
| seconds to complete. Here is what is said about the error
| "The most probable cause is that a single-threaded apartment (STA) thread
is
| not pumping messages. The STA thread is either waiting without pumping
| messages or is performing lengthy operations and is not allowing the
message
| queue to pump."
|
| I'm sorry, but I do not have a clue as to what this means. The other
| probable cause is a process is consuming too much memory. Not sure That
this
| would apply to me but perhaps opening and closing 40,000 data readers is
| sucking up memory, although I would have expected the garbage collector to
| have released this memory, but perhpas because it is all within the same
| paragraph, the memory is not being release. I often just cancel out of
the
| error message and continue with the process and it completes successfully,
so
| I don't think it is a memory issue.
| If I do not run in debug mode, I get the same error message running in
| "Release" mode.
|
| I read that you can turn off the MDA errors via the config file, but this
| does not seem to me to be the appropriate solution to the problem... Does
it?
|
| Any ideas or suggestions?
|
| Thanks in advance for your assistance!!!!
|

[OldButStillLearning]

The tables being accessed are Oracle, and while I could interject SQL Server
into the equation, I think this overly complicates things and I'm not exactly
sure why I would not run into the same issue.

I am not creating a seperate thread for this processing, but if I do this,
I'm still not quite sure how this aleviates the problem? Why would placing
this process in its' own thread now eliminate the error message that the
process is taking longer the 60 seconds? Even if I place the process in
another thread, it will still take longer then 60 seconds, so how does this
solve the problem?

If I resorted to introducing SQL Server and called a stored procedure which
invoked a DTS package, that process would, as well, take longer then 60
seconds, so how would interjecting SQL server help resolve the problem either?

Thanks in advance for your assistance.

[Willy Denoyette [MVP]]

"OldButStillLea rning" <Ol************ *****@discussio ns.microsoft.co m> wrote
in message news:01******** *************** ***********@mic rosoft.com...
| The tables being accessed are Oracle, and while I could interject SQL
Server
| into the equation, I think this overly complicates things and I'm not
exactly
| sure why I would not run into the same issue.
|
| I am not creating a seperate thread for this processing, but if I do this,
| I'm still not quite sure how this aleviates the problem? Why would
placing
| this process in its' own thread now eliminate the error message that the
| process is taking longer the 60 seconds? Even if I place the process in
| another thread, it will still take longer then 60 seconds, so how does
this
| solve the problem?
|
| If I resorted to introducing SQL Server and called a stored procedure
which
| invoked a DTS package, that process would, as well, take longer then 60
| seconds, so how would interjecting SQL server help resolve the problem
either?
|
| Thanks in advance for your assistance.
|

Well, actually you didn't answer the question why you run this on an UI
(STA) thread, but I assume it's the case. The UI (STA) thread has a message
queue that needs to get 'pumped' in a timely fashion, the CLR (in debug mode
only) will inject a ContextSwitchDe adlock" exception when you fail to pump
once per 60 secs.
So, if you want to:
- get rid of this MDA and,
- if you want your UI thread to stay responsive (which is not the case if
you block the pump), and optionally
- if you don't want to take the risk to block the finalizer thread in COM
scenarios.

you will have to move the task to another thread which doesn't have a
message queue, that is to a non UI non STA thread.

Willy.

[OldButStillLearning]

Thanks Willy, I have no real experience with thread, so I did not answer the
question, because I was not sure how to answer. I did indicate that I had
not created a thread to run this process on, which I was hoping would answer
the question as to if it was being run on a "UI (STA) thread". So If I have
not created a thread, then my assumption was that I was using the "UI (STA)
thread". So is that a good assumption?

As I mentioned, I have no experience in creating or running threads, but I
am looking at an example. Basically, I create a class which has a run method
which does all the processing that I want to have done within the thread, and
I create an instance of that class in my main procedure and then invoke the
run method. Is that about right? But I'm guessing that I need to do
something in the main procedure to "wait" for the "thread to finish" as if I
don't my procedure will terminate the program.

To do this, would I use the Thread.Sleep(XX XXX) within a while loop, which
continues to test if my "thread" is still "alive"? I created the "IsAlive"
propery in my "thread" class, but it will not complile, I get a
"'BatchJobs.SQL Thread.IsAlive. get' must declare a body because it is not
marked abstract or extern" when I place this "Property in my thread class
"public bool IsAlive { get; }"

So is this what I should be doing? What am I doing wrong?

Again, Thanks so much for your help!!!!

[Willy Denoyette [MVP]]

"OldButStillLea rning" <Ol************ *****@discussio ns.microsoft.co m> wrote
in message news:91******** *************** ***********@mic rosoft.com...
| Thanks Willy, I have no real experience with thread, so I did not answer
the
| question, because I was not sure how to answer. I did indicate that I had
| not created a thread to run this process on, which I was hoping would
answer
| the question as to if it was being run on a "UI (STA) thread". So If I
have
| not created a thread, then my assumption was that I was using the "UI
(STA)
| thread". So is that a good assumption?
|
| As I mentioned, I have no experience in creating or running threads, but I
| am looking at an example. Basically, I create a class which has a run
method
| which does all the processing that I want to have done within the thread,
and
| I create an instance of that class in my main procedure and then invoke
the
| run method. Is that about right? But I'm guessing that I need to do
| something in the main procedure to "wait" for the "thread to finish" as if
I
| don't my procedure will terminate the program.
|
| To do this, would I use the Thread.Sleep(XX XXX) within a while loop, which
| continues to test if my "thread" is still "alive"? I created the
"IsAlive"
| propery in my "thread" class, but it will not complile, I get a
| "'BatchJobs.SQL Thread.IsAlive. get' must declare a body because it is not
| marked abstract or extern" when I place this "Property in my thread class
| "public bool IsAlive { get; }"
|
| So is this what I should be doing? What am I doing wrong?
|
| Again, Thanks so much for your help!!!!
|
|

Ok, let me ask whether your application is a windows (Forms) application or
a Console style application.
If it's the former, your main thread is the UI thread and this thread has to
pump the message queue in a regular fashion, if it's the latter, your main
thread is not a UI thread and should not run in an STA, that is, you should
not decorate the Main entry with STAThreaAttribu te in order to get rid of
the MDA.
In the case of a windows application, you need to create a thread to run
your Run method. You don't have to wait for the thread procedure to finish,
especially don't call sleep in your UI thread, 'Sleep' blocks the thread for
the duration of the sleep time, something you should never do in an UI
thread.
Let your Run method update the UI when it runs to an end, note however that
you need to marshal the update call to the UI thread by calling
Control.Invoke or Control.BeginIn voke from the Run method.
Please search MSDN for details on the Thread class, Control class and
BackgroundWorke r etc...

Willy.

[OldButStillLearning]

My application is a console application.

So I can't tell if the statement "not decorate the Main entry with
STAThreaAttribu te in order to get rid of the MDA" means? Is this saying that
I do not need another thread to resolve the issue?

[Willy Denoyette [MVP]]

"OldButStillLea rning" <Ol************ *****@discussio ns.microsoft.co m> wrote
in message news:70******** *************** ***********@mic rosoft.com...
| My application is a console application.
|
| So I can't tell if the statement "not decorate the Main entry with
| STAThreaAttribu te in order to get rid of the MDA" means? Is this saying
that
| I do not need another thread to resolve the issue?

Ok, we are getting closer, seems like the Oracle provider
(System.Data.Or acleClient ?) is using COM interop, question is what are his
threading requirements.

If you have a Main method that has the STAThread attribute, something like
this:

[STAThread]
int Main(...)
..... remove the [STAThread] attribute, and you're done.

If you don't have such attribute, add the attribute like shown above.
Note that when running in a STA, you need to pump messages, that is, you may
not block the pump for too long a period.
To do so, you need to insert a pumping wait calls in your loop. One that
comes to mind is Thread.Join(), so in your loop you simply insert:

while(reader.Re ad())
{
// process data
// and pump...
System.Threadin g.Thread.Curren tThread.Join(10 );
}
....

This will insert a 'pumping wait' in the current code path for ~10 msecs.
Note however that this all won't work if a single DB command takes more than
the MDA time-out period, if that's the case, all you can do is ignore the
MDA (it should not appear when running outside of VS).

Willy.