Re: Implementation of take (multiple) in Jini starter kit
Gregg Wonderly <[email protected]>
| Newsgroups | gmane.comp.java.sun.javaspaces |
|---|---|
| Message-ID | <[email protected]> |
John McClain - Sun Microsystems, Inc. wrote: > John McClain - Sun Microsystems, Inc. wrote: > >> Gregg Wonderly wrote: >> >>> John McClain - Sun Microsystems, Inc. wrote: >>> >>>> Having said all that, for me the main motivation for the phrase "an >>>> implementation may chose to take fewer entries from the space than the >>>> maximum available or the maximum allowed by maxEntries" was so the >>>> space >>>> could protect itself from have to load all the entries into memory >>>> so it >>>> could ship them back to the client... >>> >>> >>> John, given the use of a smart proxy, and a streaming connection from >>> the server to the client, it would be possible for the server to load >>> a small number at a time, and then write those batches through the >>> stream to the client, where the client iterator could make these >>> small groups look like one batch could it not? >> >> >> Yes (though I am guessing you have to be careful about how you mark the >> entries as removed...), > > One other wrinkle, I think if take multiple was doing multiple rpc calls > (or streaming) under the covers and it got a few entries, but then one > of the call failed (or the connection was broken) before the take > completed you would have to either throw away the entries you got and > fail the whole top level call with a RemoteException, or do some sort of > fix up work with a new call (or connection) (which would be potentially > tricky and if it failed you would have to fail two whole top level call > anyway). Right, without transactions, partial failure will nip you in the backside at the most inopportune moments! It's important for everyone to have a view along the lines that RPC, socket streaming, http, SOAP etc might/should all be consider implementation details without any direct application support for "process" associated with the systematic execution of a "business" task. It is convenient to use various transports/transfer operations for varying reasons. The application should maintain the responsibility and ability to be in control of the pieces such that the outcome is predictable give any partial failure scenario. Gregg Wonderly =========================================================================== 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