Cancel Background worker in multi tier environment

[parez]

I start a BackGroundWorke r 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->Communicatio n 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
backgroundworke r and then stop it?
if i can is there anything wroong with it?

TIA

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

Re: Cancel Background worker in multi tier environment

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 BackgroundWorke r (it's not giving you anything here).

If it doesn't have a way to be called asynchronously, then I would use
the BackgroundWorke r (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.

--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"parez" <psawant@gmail. comwrote in message
news:89b928b5-c590-4d2e-abb4-ba49eed60cc9@79 g2000hsk.google groups.com...

>
I start a BackGroundWorke r 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->Communicatio n 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
backgroundworke r and then stop it?
if i can is there anything wroong with it?
>
TIA

[parez]

Re: Cancel Background worker in multi tier environment

On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

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 BackgroundWorke r (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 BackgroundWorke r (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]
- m...@spam.guard .caspershouse.c om
>
"parez" <psaw...@gmail. comwrote in message
>
news:89b928b5-c590-4d2e-abb4-ba49eed60cc9@79 g2000hsk.google groups.com...
>
>
>

I start a BackGroundWorke r 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->Communicatio n 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
backgroundworke r and then stop it?
if i can is there anything wroong with it?

>

TIA

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

Re: Cancel Background worker in multi tier environment

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 BackgroundWorke r (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]
- mvp@spam.guard. caspershouse.co m

"parez" <psawant@gmail. comwrote in message
news:f3126ad9-808b-49a3-b7ef-01f04f0fc1bd@w7 g2000hsa.google groups.com...

On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

>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 BackgroundWorke r (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 BackgroundWorke r (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]
> - m...@spam.guard .caspershouse.c om
>>
>"parez" <psaw...@gmail. comwrote in message
>>
>news:89b928b 5-c590-4d2e-abb4-ba49eed60cc9@79 g2000hsk.google groups.com...
>>
>>
>>

I start a BackGroundWorke r 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->Communicatio n 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
backgroundworke r and then stop it?
if i can is there anything wroong with it?

>>

TIA

>

[parez]

Re: Cancel Background worker in multi tier environment

On Jun 3, 2:38 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

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(communicat ion 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 BackgroundWorke r (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]
- m...@spam.guard .caspershouse.c om
>
"parez" <psaw...@gmail. comwrote in message
>
news:f3126ad9-808b-49a3-b7ef-01f04f0fc1bd@w7 g2000hsa.google groups.com...
>

On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

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 BackgroundWorke r (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 BackgroundWorke r (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]
- m...@spam.guard .caspershouse.c om

>

"parez" <psaw...@gmail. comwrote in message

>

>news:89b928b 5-c590-4d2e-abb4-ba49eed60cc9@79 g2000hsk.google groups.com...

>

I start a BackGroundWorke r 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->Communicatio n 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
backgroundworke r and then stop it?
if i can is there anything wroong with it?

>

TIA

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

Re: Cancel Background worker in multi tier environment

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]
- mvp@spam.guard. caspershouse.co m

"parez" <psawant@gmail. comwrote in message
news:a8d3c1c6-f72f-4a35-b3db-c091137cec60@m4 5g2000hsb.googl egroups.com...

On Jun 3, 2:38 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

>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(communicat ion 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 BackgroundWorke r (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]
> - m...@spam.guard .caspershouse.c om
>>
>"parez" <psaw...@gmail. comwrote in message
>>
>news:f3126ad 9-808b-49a3-b7ef-01f04f0fc1bd@w7 g2000hsa.google groups.com...
>>

On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:
>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 BackgroundWorke r (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 BackgroundWorke r (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]
> - m...@spam.guard .caspershouse.c om

>>

>"parez" <psaw...@gmail. comwrote in message

>>

>>news:89b928 b5-c590-4d2e-abb4-ba49eed60cc9@79 g2000hsk.google groups.com...

>>

I start a BackGroundWorke r 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->Communicatio n 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
backgroundworke r and then stop it?
if i can is there anything wroong with it?

>>

TIA

>

[Peter Duniho]

Re: Cancel Background worker in multi tier environment

On Tue, 03 Jun 2008 12:06:27 -0700, parez <psawant@gmail. comwrote:

On Jun 3, 2:38 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

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

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

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

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

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

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

[...]

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

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.

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).

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

Ideally, it will just gracefully throw out the query and move on. In that
case, you can safely terminate the operation at the client without
worrying about the impact on the server.

Pete

[Peter Duniho]

Re: Cancel Background worker in multi tier environment

On Tue, 03 Jun 2008 14:18:58 -0700, parez <psawant@gmail. comwrote:

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?

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.

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)

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...whatev er it is you're actually using) and an exception would be
thrown, terminating the operation.

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

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

Yup. You could. :)

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

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

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.

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.

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

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.

or
b) sync reads and Cancel Button should kill(stop) the thread

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

[parez]

Re: Cancel Background worker in multi tier environment

On Jun 3, 5:37 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Tue, 03 Jun 2008 14:18:58 -0700, parez <psaw...@gmail. comwrote:

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?

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

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)

>
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...whatev er 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.

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

>

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.

>
Yup. You could. :)
>

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

>

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

>
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 BackgroundWorke r 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.
>

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

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

or
b) sync reads and Cancel Button should kill(stop) the thread

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

[Peter Duniho]

Re: Cancel Background worker in multi tier environment

On Tue, 03 Jun 2008 15:13:55 -0700, parez <psawant@gmail. comwrote:

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)

>>
>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...whate ver 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.

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

[parez]

Re: Cancel Background worker in multi tier environment

On Jun 3, 7:24 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Tue, 03 Jun 2008 15:13:55 -0700, parez <psaw...@gmail. comwrote:

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)

>

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...whatev er 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.

>
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
RequestCancelle d Event?

[Peter Duniho]

Re: Cancel Background worker in multi tier environment

On Wed, 04 Jun 2008 06:24:43 -0700, parez <psawant@gmail. comwrote:

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

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

>
So how can i cancel the blocked read?

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

Should i raise and handle a RequestCancelle d Event?

Should you raise and handle what RequestCancelle d event?

Pete

[parez]

Re: Cancel Background worker in multi tier environment

On Jun 4, 2:10 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Wed, 04 Jun 2008 06:24:43 -0700, parez <psaw...@gmail. comwrote:

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

>

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.

>

So how can i cancel the blocked read?

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

Should i raise and handle a RequestCancelle d Event?

>
Should you raise and handle what RequestCancelle d 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..

[Peter Duniho]

Re: Cancel Background worker in multi tier environment

On Wed, 04 Jun 2008 11:43:49 -0700, parez <psawant@gmail. comwrote:

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

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

[parez]

Re: Cancel Background worker in multi tier environment

On Jun 4, 2:51 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Wed, 04 Jun 2008 11:43:49 -0700, parez <psaw...@gmail. comwrote:

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

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