RE: [picocontainer-dev] NanoWAR and session madness in Tomcat 5

> Ok, forget my previous reply.  I don't know why I didn't see it before,
> but, in fact, I am now seeing the app scope container causing a
> serialization exception.  The app still never fails to start because of a
> race condition, so I don't know what that's all about, but I do, indeed
> see
> problems when I add a component to the app scope that isn't serializable.
> 
> Does the fix involve continuing to let the session container keep its
> state
> across serialization/deserialization?

No, the current fix only allows you to bail on Session-scoped containers all
together. (Although with Mauro's suggestion, at least you don't get
double-trouble with KILLER_HELPER not serializing either) It's a compromise
since a real fix AFAICT is going to take significant work. (Basically it
seems that we'll have to rip the hierarchy apart yet make the separated
containers behave as a single unit.) And unfortunately the 1.0 release is
right around the corner.

The proposed patch (pending committers approval) is in NANOWAR-15.  It at
least allows me to use NanoWAR, (without the Session capabilities).
Otherwise, I think we're going to take a stab at it post 1.0.


<snip> <snip>
>  > >Right, but for me the non-builder script actually failed on my system
>  > >because of a race condition.
>  > >
>  >
>  >I've never, ever, seen a race condition.  Are you saying that the sample
>  >app that I provided failed for you with the pico syntax, or your own
>  >app?  I've never had a problem.  I'm using Tomcat 5.5.14.  What version
> are
>  >you using?  I don't know why that would make a difference for a race
>  >condition, but, again, it's never failed for me.

Race conditions almost never show up on a single-processor machine. (They
can, but quite infrequently and only under significant thread-stress testing
(ie, create 100 threads, and let them rip and you might see something
strange once very few runs if there was a race condition.)

The reason for this is that under a single processor machine, only one
thread at a time is truly running; but under multi-CPU machines, once you
get true multi-threaded execution, they'll show up much more frequently.  It
took me a while to really figure out what was happening: I spent about 8
hours beating my head against a wall wondering why a given Groovy script was
often returning a null picocontainer when the creation of the picocontainer
was right there in front of me! :)


>  >Is that checked in?  I've only ever had problems with the builder
> syntax.

See the patch in NANOWAR-15.  You use NanoWAR Context listener instead of
the normal listener to disable session-support.

Hope this clarifies!!
							-Mike