cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Fortress Migration Strategy
Date Thu, 16 Oct 2003 07:58:58 GMT
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

Mime
View raw message