471,354 Members | 1,659 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,354 software developers and data experts.

Cancel Background worker in multi tier environment


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
Jun 27 '08 #1
16 2271
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.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"parez" <ps*****@gmail.comwrote in message
news:89**********************************@79g2000h sk.googlegroups.com...
>
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

Jun 27 '08 #2
On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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 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]
- m...@spam.guard.caspershouse.com

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

news:89**********************************@79g2000h sk.googlegroups.com...
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
Jun 27 '08 #3
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]
- mv*@spam.guard.caspershouse.com

"parez" <ps*****@gmail.comwrote in message
news:f3**********************************@w7g2000h sa.googlegroups.com...
On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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 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]
- m...@spam.guard.caspershouse.com

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

news:89**********************************@79g2000 hsk.googlegroups.com...
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

Jun 27 '08 #4
On Jun 3, 2:38 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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(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]
- m...@spam.guard.caspershouse.com

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

news:f3**********************************@w7g2000h sa.googlegroups.com...
On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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 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]
- m...@spam.guard.caspershouse.com
"parez" <psaw...@gmail.comwrote in message
>news:89**********************************@79g2000 hsk.googlegroups.com...
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
Jun 27 '08 #5
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]
- mv*@spam.guard.caspershouse.com

"parez" <ps*****@gmail.comwrote in message
news:a8**********************************@m45g2000 hsb.googlegroups.com...
On Jun 3, 2:38 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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(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]
- m...@spam.guard.caspershouse.com

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

news:f3**********************************@w7g2000 hsa.googlegroups.com...
On Jun 3, 2:19 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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 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]
- m...@spam.guard.caspershouse.com
>"parez" <psaw...@gmail.comwrote in message
>>news:89**********************************@79g200 0hsk.googlegroups.com...
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

Jun 27 '08 #6
On Tue, 03 Jun 2008 12:06:27 -0700, parez <ps*****@gmail.comwrote:
On Jun 3, 2:38 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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.BeginRead()? 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(communication 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
Jun 27 '08 #7
On Tue, 03 Jun 2008 14:18:58 -0700, parez <ps*****@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...whatever 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(communication 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
Jun 27 '08 #8
On Jun 3, 5:37 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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...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.

What i am not able to picture is how an async operation in my last
tier(communication 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 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.
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.
Jun 27 '08 #9
On Tue, 03 Jun 2008 15:13:55 -0700, parez <ps*****@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...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.
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
Jun 27 '08 #10
On Jun 3, 7:24 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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...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.

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?
Jun 27 '08 #11
On Wed, 04 Jun 2008 06:24:43 -0700, parez <ps*****@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 RequestCancelled Event?
Should you raise and handle what RequestCancelled event?

Pete
Jun 27 '08 #12
On Jun 4, 2:10 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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 RequestCancelled Event?

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..
Jun 27 '08 #13
On Wed, 04 Jun 2008 11:43:49 -0700, parez <ps*****@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
Jun 27 '08 #14
On Jun 4, 2:51 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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.
Jun 27 '08 #15
On Thu, 05 Jun 2008 09:11:07 -0700, parez <ps*****@gmail.comwrote:
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.
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
Jun 27 '08 #16
On Jun 5, 2:33 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Thu, 05 Jun 2008 09:11:07 -0700, parez <psaw...@gmail.comwrote:
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.

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.
Jun 27 '08 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Joey Powell | last post: by
1 post views Thread by David Veeneman | last post: by
4 posts views Thread by Jesse Aufiero | last post: by
reply views Thread by Smokey Grindel | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.