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!!!!

[OldButStillLearning]

I am using the Oracle drivers (Oracle.Databas eAccess) and not the Microsoft
version of the Oracle drivers.
Yes, my "Main" method had the "[STAThread]" and I removed it as you
suggested. I had already modified my program to create a thread for the
process which is reading and looping through the database, and I can not tell
any longer if you believe that is or is not necessary. It almost sound like
you think the removal of the "[STAThread]" is going to do the trick. I have
been wanting to learn more about threading as it is something that I have a
need for in other processes, even if it turns out I do not need it here.

So by taking off the "[STAThread]", the system no longer is checking the
"pump" period? Is that the gist of what is occuring?

My test ran successfully and was not been interupted by the
"ContextSwitchD eadlock" error message, so it would appear that the issue is
resolved, but I'm not sure which action resolved it, changing the process to
run on its' own thread or removing the "[STAThread]", but I suspect that it
was the ""[STAThread]" change.

Again, thanks SOO MUCH FOR YOUR HELP!!!!!!

[Willy Denoyette [MVP]]

The STAThread attribute on Main initializes the main thread to enter a
Single Threaded Apartment (STA). STA threads need a message queue to
synchronize it's accesses, if a thread doesn't run a message queue when it
enters the STA, COM will create one on your behalf, but it's up to your code
to pump the messages. Now, without STAThread, the thread remains
uninitialized or enters the MTA and no queue gets created, effectively
removing the requirement for "pumping". That's why you won't see the MDA
again.

Willy.
"OldButStillLea rning" <Ol************ *****@discussio ns.microsoft.co m> wrote
in message news:FF******** *************** ***********@mic rosoft.com...
|I am using the Oracle drivers (Oracle.Databas eAccess) and not the Microsoft
| version of the Oracle drivers.
| Yes, my "Main" method had the "[STAThread]" and I removed it as you
| suggested. I had already modified my program to create a thread for the
| process which is reading and looping through the database, and I can not
tell
| any longer if you believe that is or is not necessary. It almost sound
like
| you think the removal of the "[STAThread]" is going to do the trick. I
have
| been wanting to learn more about threading as it is something that I have
a
| need for in other processes, even if it turns out I do not need it here.
|
| So by taking off the "[STAThread]", the system no longer is checking the
| "pump" period? Is that the gist of what is occuring?
|
| My test ran successfully and was not been interupted by the
| "ContextSwitchD eadlock" error message, so it would appear that the issue
is
| resolved, but I'm not sure which action resolved it, changing the process
to
| run on its' own thread or removing the "[STAThread]", but I suspect that
it
| was the ""[STAThread]" change.
|
| Again, thanks SOO MUCH FOR YOUR HELP!!!!!!
|

[OldButStillLearning]

OK, I thought the IDE generated the "STAThread" when it created the class for
me, but maybe not, because I have done a lot of maintenance on it and perhaps
I copied something from another class. I can't say for sure.

So what is a message que and when do I need one, as I apparently do not need
one in this instance.....

[Andy]

The message queue (I believe) is how windows tells your application
which events are raised. So your application may get a messge asking
it to refresh, handle a user click event, etc. While you are working
in the main thread, your UI can't respond to those events until your
code completes. Build a windows forms application, and add a button to
a form. IN the button click handler, add a
System.Threadin g.Thread.Curren tThread.Sleep( 10000 ) call. Then try to
move the form or drag another window over it, and notice it doesn't
repaint. Eventually the thread will 'wake up' and handle the events
(Paint, Move, etc). Unless you explicitly create another thread,
you're always working on the main thread.

Sounds like using the STAThread attribute will automatically create a
message queue (aka message pump) on the main thread.

Working with threads is fairly easy, but can also be easy to mess up.
If you're doing a Windows form application you probably will want to
use the BackgroundWorke rProcess component. It will handle a background
thread so that your UI can continue to update smoothly. It works by
creating an event handler for the components DoWork event. The code in
here is the code that will actually execute on a background thread. In
the DoWork event handler, you can raise another event to report
progress back to your ui. The UI will remain responsive instead of
blocking using this component.