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

<snip>

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

I am not sure if this thread has come to a post-agreement close,
but I have been wondering why can't it be that (thinking aloud
and waiting to hear critical comments):

* Spec says that a takeMultiple() will return <= MaxEntries
number of entries from the space - that much guarantee the
space implementation provides. In other words, if at the time
of the call,
(a) the space contains MaxEntries number of entries,
they will _always_ be returned
(b) the space contains less than MaxEntries number of entries,
but the persistent store holds the balance number of entries,
they will be loaded into the space and then, MaxEntries number
of entries will be returned
(c) the space knows that less than MaxEntries number of
entries ever existed since, they will be returned.

All the timeout aspects (blocking call) etc. are handled as they
are now.

 When I - as the caller of takeMultiple() - know the consequences
of such a call, I should not be surprised by the sudden increase
in the memory consumption or resultant hike in GC activities. That,
I think, is a fair assumption.

My 2 cents..

Nirmalya

*************************** ADVERTISEMENT ******************************
Get BT Broadband from only EUR20 per month! Always-on internet
& wireless option - find out more at http://www.btireland.ie/broadband

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