Re: outrigger internal

John McClain wrote:
> 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

Ah, just to clarify, I wasn't suggesting that there was any code at fault.

I interpreted the above as a simple request for more information - no
judgements on how it might be used ;)

I agree entirely with you that it's the nature of the beast.  For the
record, Blitz also would exhibit the exact same behaviour.  In fact, it
was after an evening spent debugging someone's app on blitz that I was
prompted to write the original piece in the guide.

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

And I'd go on record to say I wouldn't bother trying to narrow the
window cos I don't you'll ever close it fully (IMHO).

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

Yeah, I've seen similar patterns elsewhere.  You can see one variation
of that in Amazon's Queue webservice (whatever definition of web service
we're using this week! :)  It's embodied in asserting a lock on an entry
and then dequeuing it later via a separate operation.  I kind of feel
like there's sort of a reservation pattern in there somewhere.

Cheers,

Dan.

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