I think you have captured this pretty well. Some thoughts:
ALT1 - IMO the disadvantages are worse than they appear. Yes, distributed apps and DB connections exhibit this behavior, but when you are talking about ALL the cocoon components having this behavior the code will turn into nothing but error handling logic. This is just plain non-workable in my view.
ALT2 - Hmmm. You want to hot swap a singleton? Can you EVER really do that? Not only for the reasons you mentioned, but because presumably the singleton is managing stuff that is supposed to be permanently available. In this case your singleton is no longer a singleton. Frankly, I'd suggest that classes meant to be singletons should implement a Singleton (or NonSwappable or whatever) interface to prevent them from ever being reloaded. By the way - I think this is a problem for ALL the alternatives, not just this one.
ALT3 - From a client perspective, this looks just like ALT2. The client does a lookup that obtains a read lock while release does the unlock.
Since the Singleton thing makes no sense to me anyway, I'd say use ALT2.
Ralph, what about when you want to hotswap your singleton to a new version?
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
