Re: outrigger "I/O error reading from mux connection"

Lachlan O'Dea wrote:
> So, if I understand the messages you referenced correctly, this is an
> inherent problem with distributed computing and using a transaction
> is the standard way to deal with it?

Primarily, what happens is that the state of the call, from JERI's perspective is completely separate from the state of
the transport layer.  So, when the call is ready to return, there is no indication to outrigger that the return path is
not available.  The processing is done to extract the entry from the space and return it.  But, of course, it can't
return because the endpoint of the client is nolonger available/valid.  But, there is no interface between outrigger and
the JERI invocation layer, for this direction of call flow so that outrigger would know this.  Also, the calling context
is now gone from the clients perspective.  So, there is really noone to be notified of the failure.

A transaction will allow all interested parties to agree on the state of the entry in the space.  A write under a
transaction would guarentee that that entry appeared in the space, if the commit suceeds.  A take under a transaction
will guarantee that a failed take, such as this, can not be committed, and thus the entry will stay in the space and be
made available, eventually, to another appropriate take.

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

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/