Re: Depending on policy [was Re: Implementation of take (multiple) in Jini starter kit]

James Grahn wrote:
> John McClain - Sun Microsystems, Inc. wrote:
>>> Having said that, it [take multiple's option to remove fewer entries
>>> than asked for] does cause a problem for clients that know there
>>> are 10 entries in the space and they would like to be able to get them
>>> all out in one atomic call w/o bothering with a transaction.
>>
>> This brings up a general question that I would be interested to hear
>> people's opinions on.  The spec can't say "10 is safe, but 11
>> might not be (or isn't)" but individual implementation often will.
>> Indeed with Outrigger in its default configuration it is safe to pass 10
>> for maxEntries and if there are 10 entries in the space (and no
>> contention, etc., etc.) one take call will atomically remove all 10
>> entries (or remove none) w/o having to resort to loops and transactions.
>>
>> The question is how do people feel about depending on such behavior? Do
>> you feel better about if you look at the other implementations and find
>> they support similar policies (possibly after configuration)?
>>
>> Other places this comes up in the spaces world is support for
>> arbitrarily long leases (do I assume my request for a 2 day lease will
>> be granted, or do I need to be prepared to renew the lease) and how the
>> space picks what entry(ies) to return from a query when there is more
>> than one possibility (do I code assuming the space will be mostly FIFO?)
>
> Could you perhaps rephrase the question?

I can try. By there nature a specifications has to leave implementations
some wiggle room. Part of this is because you want to allow different
implementation to make different trade-offs and part of this is because
often there is no useful place to draw a line. In practice all
implementation will provide a higher level of service than the minimum
required by the specification. The question is how comfortable do people
feel writing code that depends on these "higher levels of service" that
aren't guaranteed by the specification.

One example from JavaSpaces is how many entries to return from take
multiple. The JavaSpace05 spec say if you can take multiple and there is
one or more matching entries you are guaranteed to get at least one back
(modulo contention from other clients), but the spec makes no
requirement around returning more than one entry.

The question then becomes if you are writing a JavaSpace05 client
application and you know there are two entries in the space and you want
them both removed do you write :

    while (true) {
        Collection c = space.take(templates, null, 0, 2);
        if (c.isEmpty())
            break;
    }

    or

    space.take(templates, null, 0 2);

Option one will work with any JavaSpace05 implementation, option two
will only work with some, but is a lot easier, and it seems likely that
you could configure most (all?) spaces implementations to work with
option two so what's the harm? (he asked in a devil's advocate sort of
way.) Would people feel comfortable writing code like option two even
though it was dependent on behavior not guaranteed by the spec?

--
BTW, if you want to reply to this message, please direct your reply
to the list, thanks

John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

         - David Brooks

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