cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [RT] On building on stone
Date Fri, 26 Mar 2004 11:57:31 GMT


> From: Pier Fumagalli [mailto:pier@betaversion.org] 
> 
> On 25 Mar 2004, at 17:44, Leo Sutic wrote:
> 
> > Could also be solved by introducing the notion of component 
> > transactions. Add a read and write lock to each component wire.
> > Block A could in effect disable hot-swapping of a component while it
is
> > used (i.e. get a read-lock on the wire), while the hot-swap
machinery
> > tries to get a write-lock on the wire. Thus, the component will
> > never be swapped when used, and thus the wire-check is unneccessary.
> 
> That (IMVHO) a bad approach. Components should not "lock", because 
> (anyway) that lock cannot be guaranteed...
>
> So, what's the point in "guaranteeing" the availability of a
component? 

The point is to avoid unnecessary failures by guaranteeing that the
framework
will handle events that are expected to occur in itself. There's a 
difference between a switch being unplugged (an exceptional
circumstance), 
and a block being swapped (which is quite normal).

In the exceptional circumstance you can simply release all acquired 
resources and let the exception propagate upwards to some error handler,

because it is inherent in the definition of an exception that there's
really nothing you can do about it, but a block swap should be handled 
gracefully - perhaps by trying again.

> Much _much_ better to make you completely aware that someone can 
> disconnect that wiring at any time, and you'll write your code to 
> handle it...

Yes, because every coder just loves to write error-handling code?

Either a block swap is something you should write error-handling
code for or not. If it is, then you risk the same problem as
Java has with ThreadDeathError - there's really no sensible way to 
protect against it.

If it isn't, then, well, boom.

Letting the framework handle the type of errors that *should* be
handled is good, because it moves handling for *common* *events* 
*that* *naturally* *occur* *within* *the* *system's* *specification* 
to a central point.

Trying to make the framework handle errors that are completely
outside the spec (server losing power), is bad.

Think about TCP/IP. You have guaranteed delivery of packets (which
you don't have with UDP). Completely guaranteed? No. A chopped-off
network cable is not something that the protocol can handle. But 
still very useful.

/LS


Mime
View raw message