Re: how to extend a capability on a data source?

On Nov 4, 2013, at 7:30 PM, Kevin Reid <kpreid-M/[email protected]> wrote:

> A broken promise is not one which has never been resolved, but one which has been resolved to a failure. (More precisely, a promise is resolved to another ref, which happens to be a broken ref.) A promise whose resolver is never used simply remains unresolved forever.
> 
> If the state of a promise revealed that its resolver has been dropped, then that would expose GC nondeterminism even in the single-vat case, so we don't do that.

Would a good spot to slide in transactional replication, for high-availability and failover, be with a composite handler, do you think?  

It could hold a set of Far handlers (for object replication) and RemotePromise handlers (for concurrent activity), perhaps.  Each with a non-droppable resolver and redirector and link to the far ref, through the normal objectIds, or to the remote send, through the continuationId.  

Reasons to drop a handler might include a gc of the ref, transactional replication state machine activity, rendezvous profile (timeoutBreakage), but if the last handler drops, the ref breaks.  

Dropping a handler sends a GC event to a far ref and a cancelTransaction to a send.  If a cancelTransaction is received by the send, it is really a cancelTransaction to the transactional membrane.

Any merit here?

thanks for Elib,
rob