Re: outrigger internal

Suzanne Morelli wrote:

>Hi
>
>Dan and John: thank you for your explanations.
>
>John asked whether there was a question behind the question. I'm trying to evaluate how much fault-tolerant could be an application built on top of JavaSpace if I don't use transaction. I don't plan on narrowing the window, I'm not even skilled enough to find my way in the code, let alone modifying it! The initial reason for my question was since I found nothing about that question in the spec, I was wondering how does the server of the javaSpace manage the list of "pending take operations", in particular in the case where a machine is blocked on a take, then this machine is shut down and started again and blocked again on a take (on the same JavaSpace) before any new entry arrives into the JavaSpace: how is the "taker" identified in the list? By its IP address only? (in which case I think the new entry should not be lost). I guess it's something more complex... Would you kindly enlight
  me?
>
>
Interesting question, in my mind this is something of a deep issue that
can get to the heart of distributed systems - not sure if I can
"enlighten", but will try to share my view. I could write a lot here,
but I suspect it is better to take a more interactive approach.

At some level the request is identified by/tied to the caller's thread.
This doesn't really explicitly appear in Outrigger's code, but it is the
nature of the very model presented by RMI (which is what Outrigger uses
for communication between the proxy and the server). Depending on the
RMI implementation being used you may find the association between
request and thread isn't really explicit at the RMI impl level either
(it probably would be explicit in JERI/TCP (once you get down to the TCP
MUX transport level), but probably not in JRMP or JERI/HTTP) If the
thread goes away (say because the client crashes), the result of the
request will be lost and won't be recoverable, even if the client comes
back. If the client re-submits the request it will be from a new thread
and will be considered a different request from the previous one. Given
that the death of the client is going to guarantee that we lose any
result the request produces the question then becomes can we somehow
undo any state changes made by the the request.

(One could also argue that the request is associated with/identified by
the underlying network connection that was used to make the request and
will be used to communicate the result,  there is some utility to
looking at it this way but since client death will kill the connection
too, from a failure handling point of view it is much like the request
being tied to the client's thread. (I suppose a key issue here is that
at a mechanical level it is often both the thread and the connection, so
even if the client stays up, but the connection is lost (think about a
http connection going though a proxy) you can still lose the result.))

The request being tied to the callers thread is inherent is the remote
procedure call (RPC) model. We could discuss how this is good (it is a
very natural model from the client's perspective) and bad (the sort of
thing we are talking about here), but in the end I think we would find
that the main advantage of departing from an RPC model is that certain
non-RPC models make this sort of issue more explicit, but they don't
solve the problem, you still get to the point of trying to figure out
how to make your operations transactional and/or idempotent (these
non-RPC models can make being transaction more "natural", at the cost of
some complexity in the "common" case).

If we come back to undoing state changes, one option with spaces is to
wrap everything in a transaction. Another way is to somehow close the
loop at a higher level in your application. For example if the entry
being taken represents a task to be executed, and that task is going to
generate  a result we can resubmit the task if the result does not
appear after some timeout. This way if the odd entry gets lost because a
client dies (before or after the take returns) it won't mean a task is
lost. There are a number of ways to close the loop around a take, but
which ones will work the best is generally very dependent on your
application.

Does this help?

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