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