cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@digitalinsight.com>
Subject RE: [Kernel22] How to develop a component?
Date Thu, 08 Apr 2004 17:52:15 GMT
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:leo.sutic@inspireinfrastructure.com] 
Sent: Thursday, April 08, 2004 10:29 AM
To: dev@cocoon.apache.org
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

Mime
View raw message