Re: outrigger internal

Dan Creswell wrote:
> 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 ;)

And just to be clear, I didn't read any such suggestion into your
message, seeing the the "simple request" part of the question had been
answered, I felt free to pontificate on the deeper issue :-)

[...]

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

Of course the real problem (which re-hit me as I was driving to my kid's
school for her special person week...) is even if the space could know
for certain that the client was still running when it was ready to
return from the take (which is difficult/imposable) the client could die
between the time it gets the entry back in its VM (e.g. long after the
space has had to commit to a course of action) and when the client
processes the entry - this is really functionally identical to the
client crashing before the match is found, and what ultimately drives me
to various transactional models (both formal and ad-hoc).

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

I keep on going back and forth between general but heavy weight
transaction models and lighter weight service specific ad-hoc models.

--
John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

no files, just services

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