From: OldButStillLearning on
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(XXXXX) 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.SQLThread.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!!!!


From: Willy Denoyette [MVP] on

"OldButStillLearning" <OldButStillLearning(a)discussions.microsoft.com> wrote
in message news:91CC4037-4E25-4C25-B550-7044A9DBF1BC(a)microsoft.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(XXXXX) 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.SQLThread.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 STAThreaAttribute 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.BeginInvoke from the Run method.
Please search MSDN for details on the Thread class, Control class and
BackgroundWorker etc...

Willy.



From: OldButStillLearning on
My application is a console application.

So I can't tell if the statement "not decorate the Main entry with
STAThreaAttribute in order to get rid of the MDA" means? Is this saying that
I do not need another thread to resolve the issue?
From: Willy Denoyette [MVP] on

"OldButStillLearning" <OldButStillLearning(a)discussions.microsoft.com> wrote
in message news:70D52C36-7DCC-4CB4-8D1A-D48B226FAF97(a)microsoft.com...
| My application is a console application.
|
| So I can't tell if the statement "not decorate the Main entry with
| STAThreaAttribute 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.OracleClient ?) 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.Read())
{
// process data
// and pump...
System.Threading.Thread.CurrentThread.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.









From: OldButStillLearning on
I am using the Oracle drivers (Oracle.DatabaseAccess) 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
"ContextSwitchDeadlock" 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!!!!!!