Cancel Background worker in multi tier environment

[parez]

I start a BackGroundWorker to populate a grid. It is started off in
the ui layer

The thread follows( cannot think of a better word) the path

UI->Layer1->Layer2->Communication Layer

and it blocks (the server is executing somthing where which takes
time)

How do i cancel this background worker?


Is there anyway i can access the thread object used by the
backgroundworker and then stop it?
if i can is there anything wroong with it?

TIA

 

[Nicholas Paldino [.NET/C# MVP]]

parez,

Well, tons. Does the mechanism to call the server offer a way to cancel
it? If there is, then this implies that there is an asynchronous method for
calling the server, and you should be taking advantage of that, and not
using the BackgroundWorker (it's not giving you anything here).

If it doesn't have a way to be called asynchronously, then I would use
the BackgroundWorker (or some other asynchronous mechanism) and then just
ignore it if you want to cancel the operation.

The thing is, are you doing anything that you need to cancel on the
server as well? If so, you are going to have to roll back the change on the
server, or tell the server to stop somehow.

 

[parez]

parez,


Well, tons. Does the mechanism to call the server offer a way to cancel
it? If there is, then this implies that there is an asynchronous method for
calling the server, and you should be taking advantage of that, and not
using the BackgroundWorker (it's not giving you anything here).

No there is no way to call it off.(as is) The communication layers is
blocking on a read.

If it doesn't have a way to be called asynchronously, then I would use
the BackgroundWorker (or some other asynchronous mechanism) and then just
ignore it if you want to cancel the operation.

I thought about it.Since this is a winforms app(and not a web app) , i
thought one extra thread living in the wild shouldnt be a big
problem. But as you correctly guessed I need to cancel the request
also on the server.

The thing is, are you doing anything that you need to cancel on the
server as well? If so, you are going to have to roll back the change on the
server, or tell the server to stop somehow.

There are no rolls backs needed. Just need to make sure that SQL
query, which is taking sometime to execute, stops.


I am connecting to the server over TCP/IP

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I start a BackGroundWorker to populate a grid. It is started off in
the ui layer

The thread follows( cannot think of a better word) the path

UI->Layer1->Layer2->Communication Layer

and it blocks (the server is executing somthing where which takes
time)

How do i cancel this background worker?

Is there anyway i can access the thread object used by the
backgroundworker and then stop it?
if i can is there anything wroong with it?

TIA

 

[Nicholas Paldino [.NET/C# MVP]]

parez,

You said that there is no way to cancel the operation to the server, but
there is a way to execute the query asynchronously. You can use the
BeginExecute methods on SqlCommand to execute the queries asynchronously,
there is no need for the BackgroundWorker (IMO).

Basically, if you cancel, then just ignore the callback to the
asynchronous method when it returns (you would have a flag that the callback
would check to see if the operation was cancelled or not).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

parez,


Well, tons. Does the mechanism to call the server offer a way to
cancel
it? If there is, then this implies that there is an asynchronous method
for
calling the server, and you should be taking advantage of that, and not
using the BackgroundWorker (it's not giving you anything here).

No there is no way to call it off.(as is) The communication layers is
blocking on a read.

If it doesn't have a way to be called asynchronously, then I would
use
the BackgroundWorker (or some other asynchronous mechanism) and then just
ignore it if you want to cancel the operation.

I thought about it.Since this is a winforms app(and not a web app) , i
thought one extra thread living in the wild shouldnt be a big
problem. But as you correctly guessed I need to cancel the request
also on the server.

The thing is, are you doing anything that you need to cancel on the
server as well? If so, you are going to have to roll back the change on
the
server, or tell the server to stop somehow.

There are no rolls backs needed. Just need to make sure that SQL
query, which is taking sometime to execute, stops.


I am connecting to the server over TCP/IP

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I start a BackGroundWorker to populate a grid. It is started off in
the ui layer

The thread follows( cannot think of a better word) the path

UI->Layer1->Layer2->Communication Layer

and it blocks (the server is executing somthing where which takes
time)

How do i cancel this background worker?

Is there anyway i can access the thread object used by the
backgroundworker and then stop it?
if i can is there anything wroong with it?

TIA

 

[parez]

parez,

I am not connecting to sql server. I am sending xml messages over tcp/
ip to a server.
so it would be BeginRead in my situation.

What i am not able to picture is how an async operation in my last
tier(communication tier) going to function?

Maybe thats why i took the easy route of starting the thread in UI.

You said that there is no way to cancel the operation to the server, but
there is a way to execute the query asynchronously. You can use the
BeginExecute methods on SqlCommand to execute the queries asynchronously,
there is no need for the BackgroundWorker (IMO).

Basically, if you cancel, then just ignore the callback to the
asynchronous method when it returns (you would have a flag that the callback
would check to see if the operation was cancelled or not).

Q2) Also, if i use a flag (which assume would be set by the UI) ,would
it create coupling between the UI and the last tier?
I am not trying to be JA. just trying to stick to my architecture.

After talking to my boss, I found out that even if cancel the thread,
the query will still execute on server.So I might have to go option
2(canceling thread and ignore).

But i still would like to know

- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

No there is no way to call it off.(as is) The communication layers is
blocking on a read.

I thought about it.Since this is a winforms app(and not a web app) , i
thought one extra thread living in the wild shouldnt be a big
problem. But as you correctly guessed I need to cancel the request
also on the server.
There are no rolls backs needed. Just need to make sure that SQL
query, which is taking sometime to execute, stops.

I am connecting to the server over TCP/IP

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I start a BackGroundWorker to populate a grid. It is started off in
the ui layer
The thread follows( cannot think of a better word) the path
UI->Layer1->Layer2->Communication Layer
and it blocks (the server is executing somthing where which takes
time)
How do i cancel this background worker?
Is there anyway i can access the thread object used by the
backgroundworker and then stop it?
if i can is there anything wroong with it?
TIA

 

[Nicholas Paldino [.NET/C# MVP]]

parez,

I misread in regards to issuing the command to SQL Server.

Your boss is correct in that the query will still execute on the server,
so your best bet is to have a flag in the UI layer indicating whether or not
the operation was cancelled. If the flag is true, then when the callback
returns, just ignore it.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

parez,

I am not connecting to sql server. I am sending xml messages over tcp/
ip to a server.
so it would be BeginRead in my situation.

What i am not able to picture is how an async operation in my last
tier(communication tier) going to function?

Maybe thats why i took the easy route of starting the thread in UI.

You said that there is no way to cancel the operation to the server,
but
there is a way to execute the query asynchronously. You can use the
BeginExecute methods on SqlCommand to execute the queries asynchronously,
there is no need for the BackgroundWorker (IMO).

Basically, if you cancel, then just ignore the callback to the
asynchronous method when it returns (you would have a flag that the
callback
would check to see if the operation was cancelled or not).

Q2) Also, if i use a flag (which assume would be set by the UI) ,would
it create coupling between the UI and the last tier?
I am not trying to be JA. just trying to stick to my architecture.

After talking to my boss, I found out that even if cancel the thread,
the query will still execute on server.So I might have to go option
2(canceling thread and ignore).

But i still would like to know

- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
parez,

Well, tons. Does the mechanism to call the server offer a way to
cancel
it? If there is, then this implies that there is an asynchronous
method
for
calling the server, and you should be taking advantage of that, and
not
using the BackgroundWorker (it's not giving you anything here).

No there is no way to call it off.(as is) The communication layers is
blocking on a read.

If it doesn't have a way to be called asynchronously, then I would
use
the BackgroundWorker (or some other asynchronous mechanism) and then
just
ignore it if you want to cancel the operation.

I thought about it.Since this is a winforms app(and not a web app) , i
thought one extra thread living in the wild shouldnt be a big
problem. But as you correctly guessed I need to cancel the request
also on the server.

The thing is, are you doing anything that you need to cancel on
the
server as well? If so, you are going to have to roll back the change
on
the
server, or tell the server to stop somehow.
There are no rolls backs needed. Just need to make sure that SQL
query, which is taking sometime to execute, stops.

I am connecting to the server over TCP/IP

I start a BackGroundWorker to populate a grid. It is started off in
the ui layer

The thread follows( cannot think of a better word) the path

UI->Layer1->Layer2->Communication Layer

and it blocks (the server is executing somthing where which takes
time)

How do i cancel this background worker?

Is there anyway i can access the thread object used by the
backgroundworker and then stop it?
if i can is there anything wroong with it?

TIA

 

[parez]

Stream.BeginRead()? You can close the Stream, and the operation will be
completed. Your callback will be called, and EndRead() will (should)
throw an exception.

1)
My question is how in the communication layer will I know when to
close the stream?How will the UI notify the communication layer? The
only advantage I would get by using async reads is ability to close
the socket.
Coz there is nothing else i need to do between BeginRead and EndRead
(other than may be checking the flag)

See above. How you translate that back up the tiers, depends on your
design.

2)
If i go down that path , I could throw a custom exception "Cancelled
by User" or send back an xml message (created in the communication
layer) back to the calling tier. The server sends/recieves xml
messages.

Does that mean that the UI knows about the communication layer? How does
that keep your tiers separated?

3)
What I meant was , start the thread in the UI and then kill the thread
in the UI if needed. This way UI doesn't really care what the Comm
Layer does..

So the solution to my problem could (thats more of a question)
a) Async reads in communication layer and UI shares a flag thru the
tiers with communication layer
or
b) sync reads and Cancel Button should kill(stop) the thread

[...]

Basically, if you cancel, then just ignore the callback to the
asynchronous method when it returns (you would have a flag that the
callback
would check to see if the operation was cancelled or not).

Q2) Also, if i use a flag (which assume would be set by the UI) ,would
it create coupling between the UI and the last tier?
I am not trying to be JA. just trying to stick to my architecture.

Not sure what "JA" is. But just because you have a flag, that doesn't
mean that the UI knows about it. It just means that you've got something
in your design that allows the flag to be set by the UI.

JA=JACK-ASS. I just wanted to make sure i don't sound to picky..

What layers need to know about the flag and how they deal with it depend
on your larger design. That's up to you to decide.


What will the server do if the connection on which the request was made
winds up closed before it can reply?

Its an AS/400 server and hes' not really sure..but he said it will
not finish(I am not gonna say anything bad about him coz he is going
to read this post )

 

[parez]

I don't know. That's dependent on design characterstics that I know
nothing about. It would be up to you to decide what the API between your
layers is/looks like.


I don't see how the async/sync API affects this. Even if you used the
sync API, but called it from a thread, you could close the Stream (or
Socket...whatever it is you're actually using) and an exception would be
thrown, terminating the operation.

1)
If I use sync api, I would be blocking on the read hence not able to
close the socket.

Yup. You could.



Well, the UI doesn't need to care one way or the other.

But if the communications layer exposes only a synchronous API, then a
higher layer (UI?) will have to wrap that so that the UI itself can
proceed without waiting on the synchronous API. On the other hand, if the
communications layer exposes an async API, it can implement that
internally by wrapping synchronous calls with a thread, or by using
asynchronous calls itself.

The communication layer exposes a synchronous processmessage method.
Thats why i have the UI create a BackgroundWorker process so that
the user can navigate around the application when this data is being
retrieved.

Make sure you aren't confusing questions pertaining to the interface
between layers with questions pertaining to how each layer is actually
implemented. The two may be related on occasion, but they don't
necessarily restrict answers to the other.


The flag is only necessary if your approach to canceling is to let the
operation proceed, but ignore the results. Whether you use a flag to
implement the canceling behavior is independent of whether the
communication layer exposes an async API or not.

The reason why I think it is dependent is because of 1)

Nothing should ever "kill" a thread. Any threads you start, they should
complete naturally. You can do this by letting them just finish, or by
providing a way to interrupt the operation (e.g. closing an i/o object).
But please don't go killing threads.

Pete

And I will be nicer to threads.

 

[parez]

That's not true. You can't close the socket from the thread that's
blocking, but that's trivially obvious and not relevant. You can close
the socket from whatever thread needs to interrupt the thread that's
blocking. A blocking read can be interrupted just as easily as a
non-blocking read.

Pete

So how can i cancel the blocked read? Should i raise and handle a
RequestCancelled Event?

 

[parez]

Same as you cancel a non-blocking read: close the i/o object.


Should you raise and handle what RequestCancelled event?

Pete

what i am trying to ask is which thread will/should close the i/o
object? since the current thread is blocked on the read, i thougtt i
could create a RequestCancled event which would be raised by the UI
and it could be handled by the communciation Layer or any other
layer..

 

[parez]

You could do that. But I don't see the point. It would mean that the
communication layer would wind up not just a service that your GUI uses,
but also as an active user/subscriber of the API that your GUI exposes.

Why not just have a method in your communication layer that the GUI can
call to cancel the i/o? Which thread it's called from doesn't really
matter; it just depends on what circumstance causes you to want to cancel
the i/o. If it's a user pushing a "Cancel" button, it'll probably be the
GUI thread that calls the method. If it's a timer or response to some
other condition, it could be some other thread (as appropriate to the
timer or other condition).

Pete

Hmm.. This means I will have to create another path down the tiers
for request cancellations and also keep a reference of the objects of
the underylying tier so i can traverse down to the blocked object.

Thanks Pete and rest for the replies.

 

[parez]

Yes. But I don't see how that wouldn't be the case regardless of the i/o
implementation. You can't cancel something unless you know what that
something is.

Pete

Yea.. When i designed it, I didn't consider the cancellation
possibillity or a need to follow an existing object trail.Its small
change though.

Thanks for your input.