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

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

John McClain - Sun Microsystems, Inc. wrote:
> James Grahn wrote:
>> John McClain - Sun Microsystems, Inc. wrote:
>>> James Grahn wrote:

[....]

>>>> and that will adhere to our expected behavior.
>>>
>>> What is the behavior you expect?
>>
>> That take multiple will take maxEntries entries from the space if
>> maxEntries exist (allowing for other things like availability, timeouts,
>> etc).   Integer.MAX_VALUE is a reasonable limit on this, since we should
>> have far fewer entries in space than that.
>>
>> We expected that behavior because the maxEntries parameter seemingly
>> allows for the previously mentioned optimizations without any need to
>> change the configuration.   We had not anticipated an external
>> configuration setting would override the maxEntries parameter (despite
>> the javadoc proviso).
>
> FWIW, the trade-off in my head was (and I am more just musing than
> defending here...it has been observed that I like to hear my self
> talk....):
>
>   o RPC-type calls that are to return arbitrary large chunks of data
>     are problematic (memory, latency, etc.) for both the client and
>     server,
>
>   o from a spec perspective it is very hard to say "10 is safe, but
>     11" might not be (or isn't)",
>
>   o in any concurrent container (like spaces) the notion of getting
>     "all" of anything is suspect, and
>
>   o give how I expected most people to use batch variant of take
>     forcing clients to put their takes in a loop doesn't seem like
>     a big deal.
>
> Having said that, it 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. Though I
> wonder in reality how likely is it that you know there are at most 10
> entries, transactions aren't an option, and the removal of the 10
> entries has to be atomic on the space (as opposed to globally in your
> application but managed at a higher level than individual space ops)

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