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

John,
Previously, we misunderstood the semantic of take(templates,
transaction,0,maxEntries) as

"take maxEntries matching entries in space"

instead of

"take maxEntries matching entries in space, except when your
javaspace instance configuration dictates a smaller bounding number"

Now that we realized such stipulation with the function, writing a
loop to ensure thorough "takes" will be sensible. The only possible
danger of the semantic is that if another remote process is writing
matching entries at a similar or higher rate of the taking, the loop
can be infinite.

On Aug 16, 2006, at 9:00 AM, John McClain - Sun Microsystems, Inc.
wrote:

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

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