Re: outrigger internal

Dan Creswell wrote:

> Suzanne Morelli wrote:
>
>> Hi,
>>
>> I've read in Dan Creswell's JavaSpaces Guide
>> (http://www.dancres.org/cottage/javaspaces.html#commonques) that
>> outrigger maintains a list of "pending takes" which may cause a new
>> entry to be lost if the computer which was blocked on a take is shut
>> down before the new entry becomes available into the space.
>>
>> I certainly believe him but I would like to known where to find the
>> code associated with his explanation. I get lost browsing through
>> OutriggerSpaceImpl, OperationJournal etc. Which source file /
>> attribute / method should I be looking at?
>>
>
> OutriggerServerImpl::getMatch(EntryRep tmpl, Transaction tr, long
> timeout, boolean takeIt,
>                 boolean ifExists, QueryCookie queryCookieFromClient)
>        throws RemoteException, InterruptedException, TransactionException
>
> In particular the QueryWatcher stuff.
>
> For Blitz, you would need to look at SearchTasks and SpaceImpl.

I am going to take a different position here, in that the issue isn't
with any particular piece of code or coding technique, but with the
fundamental nature of remote non-idempotent operations. While there are
things Outrigger could do (and has done in the past) to narrow the
window where an entry could be lost, there is no way to close the window
without making the operation somehow transactional[*]  (which of course
is an option with takes on a JavaSpace). Even with a transactional
approach there are likely to be modes where entries can be effectively
`lost' (e.g. they become locked forever, the alternative is modes where
a client thinks it has the entry, but it really doesn't) - the advantage
of a transactional approach is it tends to make entry loss, much, much,
much less likely - often to the point where you no longer care.

If your are interested in narrowing the window, then Dan points out the
right piece of code, the window is bigger in Outrigger 2.n than it was
in 1.n because in 2.n blocking queries block in the server, not in the
client.

Is there a question behind the question?

[*] It occurs to me that an interesting variation on the spaces model
would be a "soft take" that made it improbable that another client would
get the same entry, but did not eliminate the possibility (e.g. weaken
the exclusivity guarantee associated with take). You could imagine that
entrys that had been soft taken would be moved to the "back of the
queue" and only returned to other clients if there were no other
matches.  An entry that had been soft taken would only be permanently
removed if it was taken by a std. take, or if one the clients that had
gotten the entry by a soft take somehow confirmed it had processed the
entry (you could imagine this being implicit in some other operation).

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