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 -----Original Message----- From: Leo Sutic [mailto:[EMAIL PROTECTED] Sent: Thursday, April 08, 2004 10:29 AM To: [EMAIL PROTECTED] Subject: RE: [Kernel22] How to develop a component? SCENARIO: Client uses component. Component is to be hot-swapped. What does client percieve when component is swapped? I.e. from the client's point of view, what happens? And these are the alternatives that I know about... ALT1: Wires are severed immediately, the component is reloaded. Advantages: We know what happens with some certainty. The client will get a big fat InvalidWireException thrown in its face, and have to deal with it - but we know that this will happen and can thus code for it. This is what happens when you run a distributed app / DB connection pool, so it's really not something that's unheard of. Disadvantages: Coding for that InvalidWireException can turn into a mess. ALT2: Wires are left intact and the new component is loaded in parallell with the existing component. All future lookup() operations will return a wire to the new component, and the old component will be undeployed when all wires to it has been release()'d. Advantages: A smooth phasing-in of the new code. No exceptions thrown. Disadvantages: A bit of a problem if the component was supposed to be a singleton, or if it accesses some shared resource, such as a log file. Suddenly, you have two instances of something that should only have one instance. Additionally, you'll never know if there is some wire that's unreleased, so if you hotswapped a component due to a serious security fix, you can't ever find out if the new code is really running everywhere in the system. ALT3: Slap a read-write lock on every wire. When a component is about to be undeployed, get a write lock on every wire before severing them. Client must do a lock()/unlock() operation around blocks of code where it can't handle the severing of a wire. Advantages: Works perfectly well in theory. Disadvantages: Deadlocks - but we can make lock() fail instead of block to get around this. Perhaps. Harder to implement than alt 1 or 2. /LS
