Aaron Mulder wrote:
Couldn't we construct the new stack "next to" the old one, and then "swap it in" at the beginning of the next invocation? That way the old invocation completes against the complete old stack, getNext() has no problems, etc. but new invocations complete against the complete new stack.
Kind of, but we need to know when the 'next' invocation is - I think it is best if all invocations in the same transaction use the same stack.
I think this means we need some form of global config version id which can be included into a transaction, or maybe we can determine this from a global transaction id. Anyway, the thought of multiple concurrent versions of the same container gives me the creeps and for now KISS says just stop, reconfigure and restart :-)
Whatever we come up with for this though, I don't think it affects the switch to building the stack from the inside out.
-- Jeremy
