Considering I often publicly relate my lack of insight into
multithreading issues here is a question :) :
Would it heavy handed (and cumbersome) to persist something about the
message (like the id) so when it arrives and is handled it can be
checked upon Receive to know what action to take, defaulting to a Null
action if it has been dealt with? Are we dealing with how to
concurrently handle the state of a message? Maybe persist a state
object for the message before sending?

On Jan 26, 9:56 am, Ayende Rahien <[email protected]> wrote:
> That is really annoying to me, but I am not sure what we can do to
> successfully resolve this issue.
>
> On Mon, Jan 26, 2009 at 11:46 AM, Ayende Rahien <[email protected]> wrote:
> > It is more than that, actually, we handle some things in the peek directly
> > (to support move to sub queue.I think that this is going to change, so we
> > only ever deal with things in a transaction after a recieve
>
> > On Sun, Jan 25, 2009 at 1:23 AM, Ayende Rahien <[email protected]> wrote:
>
> >> How would you do that, and how would this help?
>
> >> the actual problem is that we can get into a situation where we process a
> >> message on several threads on the same time.
> >> It just happened to be the case that this is not something that we
> >> actually do (because receive will take care of that), but it seems like an
> >> aweful lot of waste to do it in this fashion.
>
> >> On Sun, Jan 25, 2009 at 1:20 AM, Mike Nichols 
> >> <[email protected]>wrote:
>
> >>> Putting the Thread Id in the message itself to be evaluated onpeek?
>
> >>> On Jan 24, 11:06 pm, Ayende Rahien <[email protected]> wrote:
> >>> > The threading model for the bus is done by spawning multiple Begin Peek
> >>> > calls.
> >>> > That is causing a problem because when a message arrives, we get
> >>> notified
> >>> > for the _same_ message on all threads.
> >>> > I am not sure how to resolve this issue.
> >>> > Any ideas?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to