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

Stefan Schulz wrote:
> Dan Creswell wrote:
>> 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.
>  >
>
> Maybe this provides a comparable real world scenario: Let us have a
> blackboard, where Calls for Papers are posted. Now, short-brained Ph.D.
> students (like me) read a newly posted CfP and produce according papers.
> As long as the students only react and see newly posted CfPs, this works
> fine.
> If we add an iteration mode, i.e., students regularily scan all
> available CfPs to write papers for each one (of course only one paper
> per CfP), they have to memorize the CfPs they have written papers for,
> i.e., either they log the information or they tag the CfP. In the first
> case, the log might get quite big over time, in the second case, they
> need write access to the CfP.
>
> Does this help?
>

Not sure - let's see:

If each CfP had a unique id, students posting papers could place that
same id on their paper and thus for any CfP it would be easy to locate
all associated papers.

So, I think this works:

public class CallForPapers implements Entry {
        public Uuid _uniqueId; // Uuid is a standard JINI 2.x class
        public String _title;
        public String _description;
        ......
}

public class Paper implements Entry {
        public Uuid _cfpUniqueId;
        ......
}

"Students" would registerForAvailabilityEvent() a template of type
CallForPapers which would catch all newly written CfPs.  If students
wanted to look at previous postings they'd missed they'd would also do a
contents().

When someone wants to collect up all the results they'd do:

take(new CallForPapers(uniqueId), null, ....);

And then:

Paper myTemplate = new Paper(uniqueId);
Paper myPaper = null;
while ((myPaper = take(myTemplate, null, .....)) != null) {
        // Do something with the paper.....
}

// Once we get here, there are no more papers.

Something that would need some worrying about is to ensure "Students"
don't submit a paper too late.  That could be done by having a drop-dead
date in the CallForPapers Entry.  If you had such a date, you could do
something more general like having a Collator that could locate all
expired CallForPapers instances and grab the appropriate associated
Paper Entrys.  "Students" would know not to generate a paper by
examining the drop-dead date and figuring out if they can submit in time.

Now, how does a "student" know if they've submitted a paper for a CfP or
not?  Well, if each "student" has a unique id they can do a:

read(new Paper(cfpUniqueId, studentId));

And if that returns non-null, they know they've already posted.  i.e.
We can use the fact that posting a paper lodges an Entry of type Paper
to determine if we've submitted or not.  Thus we don't need to modify
the existing CfP Entry nor do we need to log the submission at the
"student".

Caveat:  All the above is off the top of my head and may or may not suit
your requirements.


Hope that helps,

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/