Pumping actions!

[tc]

I have a routine that need to process individual records in data tables,
change values, and add other records to other tables for history purposes.
This may be one or two records, it could be several thousand depending upon
what the user has selected in a grid.

On a long run (large loop) I get the following error on the development
machine:

The thread that owns the destination context/apartment is most likely either
doing a non pumping wait or processing a very long running operation without
pumping Windows messages. This situation generally has a negative
performance impact and may even lead to the application becoming non
responsive or memory usage accumulating continually over time. To avoid this
problem, all single threaded apartment (STA) threads should use pumping wait
primitives (such as CoWaitForMultipleHandles) and routinely pump messages
during long running operations.

My SQL code is a simple sub:

If DBType = "MSSQL" Then
Dim con As New SqlConnection(MsSqlConnString)
con.Open()
Try
Dim tr As SqlTransaction =
con.BeginTransaction(IsolationLevel.ReadCommitted)
Dim com As New SqlCommand(sql, con, tr)
com.ExecuteNonQuery()
tr.Commit()
com = Nothing
tr = Nothing
If Left(LCase(sql), 6) = "insert" Then
Dim lid As New SqlCommand("SELECT @@IDENTITY", con)
LastID = CLng(lid.ExecuteScalar)
lid.Dispose()
End If
Catch ex As Exception
con.Close()
MsgBox(ex.ToString & vbCrLf & vbCrLf & sql)
End Try
con.Close()
con.Dispose()
End If

There is obviously something happening here that shouldn't, can anyone
explain why the threads are getting messed up with such simple code? And
how to setup pumping?

Thanks,
TC.

 

[Armin Zingler]

I have a routine that need to process individual records in data
tables, change values, and add other records to other tables for
history purposes. This may be one or two records, it could be
several thousand depending upon what the user has selected in a
grid.

On a long run (large loop) I get the following error on the
development machine:

The thread that owns the destination context/apartment is most
likely either doing a non pumping wait or processing a very long
running operation without pumping Windows messages. This situation
generally has a negative
performance impact and may even lead to the application becoming non
responsive or memory usage accumulating continually over time. To
avoid this problem, all single threaded apartment (STA) threads
should use pumping wait primitives (such as
CoWaitForMultipleHandles) and routinely pump messages during long
running operations.

When do you get this message?

My SQL code is a simple sub:

There is obviously something happening here that shouldn't, can
anyone explain why the threads are getting messed up with such
simple code?  And how to setup pumping?[/QUOTE]

If you don't want the user interface to be blocked, you have to put the work
in another thread.


Armin

 

[Kr3at]

Its hard to tell imediately, as there are many factors involved. Is
the SQL local or remote, is there a network connectectivity issue?
Have you monitored bandwidth/CPU usage while the command executes? In
any ASP.NET process that uses to much Memory or CPU usage, you run the
risk of the application recycling in IIS, at least when running from a
web server.

Immediately looking at your code, I see that your first SQL Command is
part of the transaction, but the seconed is not part of the
transaction.

 

[AlexS]

Did you put Application.DoEvents call into loop?

 

[Phillip Taylor]

Its hard to tell imediately, as there are many factors involved. Is
the SQL local or remote, is there a network connectectivity issue?
Have you monitored bandwidth/CPU usage while the command executes? In
any ASP.NET process that uses to much Memory or CPU usage, you run the
risk of the application recycling in IIS, at least when running from a
web server.

Immediately looking at your code, I see that your first SQL Command is
part of the transaction, but the seconed is not part of the
transaction.

Sorry

I can't send a new post to this group using google groups. Does anyone
know any problems or why? sorry for thread stealing.

 

[tc]

The first part of the sql routine is used to add, edit records, if the
command is an insert the second part of the code returns the scalar. Are
you saying this should be part of the transaction?

 

[tc]

The problem is, there are a large number of options available to the user,
any one of which could change a view in the grid I'm working from. So
adding a DoEvents allows the user to mess up the operation.

Without running loads of code to turn on and off certain functionality,
acording the users input would be incredibly time consuming. This is a very
large app.

 

[tc]

It's not always the same. It usually happens around 3000 transactions.

I do want the interface blocked as there are many actions that could mess up
the visible data I'm working with. So I can't use DoEvents to help
processing.

It's all local, network trafic on the server never gets above 5%, although
the CPU gets up to around 25%, but it's only a Dell Precision 380.

So there are no network bottle necks.

I have a routine that need to process individual records in data
tables, change values, and add other records to other tables for
history purposes. This may be one or two records, it could be
several thousand depending upon what the user has selected in a
grid.

On a long run (large loop) I get the following error on the
development machine:

The thread that owns the destination context/apartment is most
likely either doing a non pumping wait or processing a very long
running operation without pumping Windows messages. This situation
generally has a negative
performance impact and may even lead to the application becoming non
responsive or memory usage accumulating continually over time. To
avoid this problem, all single threaded apartment (STA) threads
should use pumping wait primitives (such as
CoWaitForMultipleHandles) and routinely pump messages during long
running operations.

When do you get this message?

My SQL code is a simple sub:

There is obviously something happening here that shouldn't, can
anyone explain why the threads are getting messed up with such
simple code?  And how to setup pumping?[/QUOTE]

If you don't want the user interface to be blocked, you have to put the
work in another thread.


Armin[/QUOTE]

 

[AlexS]

Not sure I understand your issue however

- you can set cursor to hourglass before loop and reset it back to original
one after loop completes. Or disable-enable grid. Or something else similar.

In your case I would consider running this long update on another thread -
check BackgroundWorker or ThreadStart classes. Then your UI thread would
pump properly. But in any case, if user can mess up UI during this long
operation, you need to prevent this.

 

[Armin Zingler]

It's not always the same. It usually happens around 3000
transactions.

I do want the interface blocked as there are many actions that could
mess up the visible data I'm working with. So I can't use DoEvents
to help processing.

I won't suggest Doevents, and I understand that you want to keep it in the
UI thread, though I've never seen this message, that's why I asked when you
get it. Just when sitting in front and watching? When clicking on the not
responding Form?


Armin

 

[Armin Zingler]

In addition:
You still can put it in another thread and show a modal Form (.ShowDialog)
in your UI thread in order to prevent the user from working with it. Though,
I'm still interested when you get the error message.


Armin