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
smime.p7s
Description: S/MIME cryptographic signature
