Nathaniel Alfred <Alfred.Nathaniel <at> swx.com> writes:

> > As you can see on every request a new wrapper is instantiated
> > which is really
> > bad. It is not possible to synchronize on Cocoon session
> > objects. What we
> > probably need is a Map mapping the server sessions to the
> > wrapper objects.
>
> Servlet API [1] says "Session information is scoped only to the current
> web application (ServletContext), so information stored in one context will
> not be directly visible in another."  I read that as "A new session object
> must be create for requests in different contexts and may be create for
> requests in the same context."

Though I see your point I don't know if I can follow your interpretation.

> So the circumstances under which synchronized(session) works is dependent
> on the servlet implementation.

I can not imagine that such an important point is not metioned in the
servlet
spec. I have already downloaded it, but did not had a look into it for this
point.

> But the String pool comes to the rescue.  This should work for all
> sessions within the same JVM:
>
>    synchronized(session.getId().intern()) {
>       ...
>    }

That's not more than a work around IMO.

Furthermore your interpretation seems not to be common sense in Cocoon
project:

"synchronized[ ]?\(session\)" - 16 matches in project Cocoon 2.1.7

core:
org.apache.cocoon.Cocoon (1 match)

authentication-fw:
org.apache.cocoon.webapps.authentication.generation.ConfigurationGenerator
(1 match)

portal-fw:
org.apache.cocoon.webapps.portal.components.PortalManagerImpl (4 matches)

session-fw:
org.apache.cocoon.webapps.session.components.DefaultFormManager (2 matches)
org.apache.cocoon.webapps.session.components.DefaultContextManager (5
matches)
org.apache.cocoon.webapps.session.components.DefaultSessionManager (1 match)

xsp:
org.apache.cocoon.components.xscript.XScriptManagerImpl (1 match)
org.apache.cocoon.components.language.markup.xsp.XSPUtil (1 match)

Joerg

Reply via email to