incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Space/outrigger suggestions
Date Mon, 20 Dec 2010 16:54:41 GMT
Glad to explain.

My argument is a bit simplistic; as a matter of API design, it's preferable to have a single
return mechanism for multiple returns.

I realize there were likely technical reasons for the decision, but it makes for a less uniform
API and in particular becomes a greater concern if we elect to add new method signatures returning
multiple items.

I'm not clear on what you mean by the "non-destructive" nature of contents() requiring a remote
iterator to be useful.   At my company, we actually wrapped the method to so that we'd ultimately
get a collection (by exhausting the iterator).

Also, contents() presumably sets 'read' locks if a transaction is used, creating reservations
for future takes, so doesn't the level of 'destructiveness' depend on usage?

Now, that's not to say I'm deadset against the remote iterator approach.   Remote iterators
might save some memory/cpu overhead for truly massive requests, particularly if the user does
not necessarily want every entry (though were that the case, maxEntries should have been used).

On the other hand, returning a collection would spare network costs of sustained remote iterator
interactions and the mild timing uncertainties its usage entails.   And the remote iterator
is more complex by its nature.

In any case, I think it would be best to standardize on one or the other.

Perhaps as someone involved with Javaspace05, you can illuminate some of the decision making
surrounding the current usage of both?


-----Original Message-----
From: "Dan Creswell" <>
Sent: Monday, December 20, 2010 4:19am
Subject: Re: Space/outrigger suggestions

James G,

Can you explain some more about this statement please?

"3) Collections or remote iterators, not both.

"contents" returns a remote iterator named "MatchSet", while "take (with
collection)" returns a collection.   I can understand the argument
behind both use cases, but not necessarily the argument for using both


This has been heavily discussed in the past and contents(), by virtue of
it's non-destructive nature (unlike take) needs something akin to a remote
iterator to be practical/useful. Multiple takes allow you to eventually
exhaust a space's contents, multiple reads won't do similarly.

So, given I'm scarred with the previous efforts of space implementation
including JavaSpace05 I fear my past is colouring my thinking so I'd like to
understand more.



View raw message