Re: Pattern for One-Entry-Multiple-Workers Problem

Stefan Schulz wrote:
> Dan Creswell wrote:
>> Yes, you could do that though if all your Workers want that Entry
>> you'll obviously get conflict/potential reduction in concurrency
>> though this can be avoided to a certain degree with reasonably smart
>> (though not trivial) worker code.
>
> You are right, this definitely will be a problem.
>
>> Regardless, it sounds like you may be migrating towards a need to do
>> this take() kind of thing in which case a unique id is a useful thing
>> to have lying around.
>
> Hm, after some thoughts, this notification seems only to help, if I
> really do not take and modify entries, as a worker will be notified, if
> he himself or any other worker puts an entry to the space matching a
> template the Worker registered (which would happen in my case, as it
> would only modify the original object and not the entry's properties).
> On the other hand, if the entry is signed, the worker would not (try to)
> take it again, so it would only be a reading overhead.
>

Does the Worker really need to modify the original Entry or could it
write a new one?  If one had a unique id on the original Entry and put
the same id into the Entry produced by the worker, would that not be
good enough?

Why do you need the worker to modify the original Entry - i.e. what's
the requirement you're trying to solve by updating the original Entry?
There may be other options if we understand more about the problem
you're trying to solve.

>> Well, one reason is to ensure that users don't mistakenly think the
>  > Entry in the event is _the_ entry.
>
> But the entry in the event will contain a copy of the original object,
> too, won't it? Not only the (visible) fields.
>

Sorry, badly phrased - this has to do with Entry identity or the fact
that there isn't any.  Sure it's a full copy but there could be more
than one Entry written to the space and just because you use the copy
received in the event to do a take provides no guarentee of which Entry
you'll actually take.  The taken Entry might be the one that generated
the original event or it might be some other Entry written at some other
point in time.

>
> In the end, there is still the alternative to (externally) trigger a
> contents()/iterator-base operation, as mentioned by Gregg. Although, not
> very elegant, maybe the easiest and most complete way to do it. Hm.
>

I think this can be avoided if we can understand why you want to modify
the original Entry - I'm sure there will be ways around this.

Dan.

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/