Leo Sutic wrote:
>
> Stephen, Berin,
>
> I think Cocoon uses a stack-based scheme that can be implemented by the
> container,
> although it can't be exposed to those that only see the
> Component/ServiceManager
> interface.
>
> This is pretty much how it works:
>
> 1. Define a method called beginProcessing in the container. This method
> creates a Collection of component instances and pushes it onto a
> Thread-Local stack. Note the thread-local thingy.
>
> 2. Every call to lookup will look at the top of the stack, and if it
> finds a Collection there, add the instance it returns to that
> Collection.
>
> 3. Every release will remove the component from any Collection in the
> stack. This is O(n) in the number of invocations of beginProcessing.
>
> 4. Finally, define a method endProcessing that pops the top Collection
> from the stack, and releases all components in it.
>
> 5. Code like this:
> beginProcessing (); // Checkpoint
> try {
> doStuff (request);
> } finally {
> endProcessing (); // Rollback to previous checkpoint, i.e. four
> lines back
> }
>
> What does this mean? Well, it means that when endProcessing is called,
> any components
> lookup'ed in the thread doing the doStuff() are released.
>
> Think of it this way - we can consider everything to be single-threaded,
> since we
> only deal with thread local variables. When we enter doStuff we know
> that no components
> have been looked up. Then doStuff does stuff. Now, we have a record of
> all components
> that have been looked up but not released in the Collection where we put
> them in step
> (2) above. So endProcessing releases them.
>
> I think this (a) how it works in Cocoon now, and a per-request
> lifecycle/lifestyle.
>
Yes, that's basically how it works with one important addition.
The current set of components is not always the top of the stack
due to the sax based streaming.
- a request comes into cocoon, the empty collection is put on the
stack
- a sub request is created, another empty collection is put
on the stack.
- sax based streaming from the sub request is started and
directly streamed to the main request.
So in this sax streaming we have a class called
EnvironmentChanger that takes care that the current collection
used is the correct one.
So if the sub request sends an event to the main request,
a pointer is set pointing to the collection of the main
request. When this event is finished it is reset.
This is a very complicated thing, I really would like to get rid
off - but without loosing the functionality of course.
Carsten
