cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [RT] On building on stone
Date Thu, 25 Mar 2004 23:18:39 GMT
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...

Imagine this: I have a JDBC connection block upon which instantiates 
java.sql.Connection components...

Kewl, I make it transactional, the framework GUARANTEES me that I'm not 
going to loose it...

Whops, my network administrator (happened today at noon) reinstalling 
the firewall accidentally disconnects the power cable of the switch...

IOExceptions thrown everywhere... Now, if my component (using the JDBC 
connection) is not ready to handle that, my website falls over (and 
VNUNET did fall over today at noon).

So, what's the point in "guaranteeing" the availability of a component? 
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...

To handle it if the framework unwires your JDBC connection instance, 
and to handle it if you have an IOException because your admin 
unplugged a cable.

Let's not over-think our problems... :-P

	Pier

Mime
View raw message