On 16.05.2005 06:39, Ralph Goers wrote:
Yes, there was considerable discussion about this.
Yes, the version in svn is wrong. I was hoping it would get fixed after
our discussion, but that hasn't happened, so I'll try to commit
something tonight (it is still Sunday night here in California).
Please update from svn and review the changes.
Ralhp
Jochen Kuhnle wrote:
Am I not getting it, or is the implementation broken (see below)?
/** The map to assure 1:1-mapping of server sessions and Cocoon session
wrappers */
private static final Map sessions = Collections.synchronizedMap(new
Am I not getting it, or is the implementation broken (see below)?
/** The map to assure 1:1-mapping of server sessions and Cocoon session
wrappers */
private static final Map sessions = Collections.synchronizedMap(new
WeakHashMap());
public Session getSession(boolean create) {
Yes, there was considerable discussion about this.
Yes, the version in svn is wrong. I was hoping it would get fixed after
our discussion, but that hasn't happened, so I'll try to commit
something tonight (it is still Sunday night here in California).
Ralph
Jochen Kuhnle wrote:
Am I not
: Donnerstag, 12. Mai 2005 18:27
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
In addition, I really don't like the implementation that was checked
in. Frankly, this is a case where I would look into leveraging
backport-util-concurrent
(http
Fine. Leave the WeakHashmap the way it is. But synchronizing on the
servlet session is a -1 for me. That could have unknown consequences
since the object is owned by the container, not Cocoon. See my other
post. Sorry - my ISP has had severe email problems the last few days
and so I have
Nathaniel Alfred wrote:
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 11. Mai 2005 18:04
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes
It suddenly dawned on me that the code below is synchronizing on the
session, not a local object. Duh! Still, this seems like a very, very
bad idea to me, as I'm not sure how that would impact the servlet container.
public Session getSession(boolean create) {
// we must assure a 1:1-mapping
I ran through this thread and made some observations:
1. There can only be one Cocoon Session per HttpSession. Creation of
this must be thread safe.
2. The code propsed will not work:
public Session getSession(boolean create) {
// we must assure a 1:1-mapping of server session to cocoon
Ralph Goers Ralph.Goers at dslextreme.com writes:
serverSession is a local variable. Synchronizing it accomplishes nothing
since every caller gets their own copy. Sytnchronizing on a member of
the HttpRequest object also accomplishes nothing.
Huh? Why shall synchronization not work? It is
Sylvain Wallez sylvain at apache.org writes:
This approach has the problem of entering a synchronized block each time
getSession is called. Although this may not that be much a problem in
this particular case because it's unlikely that many parallel requests
exist for a single request, we
Sylvain Wallez sylvain at apache.org writes:
Or more simply we could store the wrapper in the session itself using an
attribute. That way it would be guaranteed to be created only once.
Yes, that's another possibility I also had in mind. But on the one hand
this smells a bit
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes:
Or more simply we could store the wrapper in the session itself using an
attribute. That way it would be guaranteed to be created only once.
Yes, that's another possibility I also had in mind. But on the one
Sylvain Wallez sylvain at apache.org writes:
This solution looks really cool and elegant. Unfortunately
HttpSessionActivationListener is Servlet Spec 2.3. In Cocoon 2.1. we are
still on 2.2 and I guess (and suggest) we will stay with that. So only the
WeakHashMap solution remains.
2.2,
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Donnerstag, 12. Mai 2005 11:16
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
I have an implementation with map in HttpRequest and without
double-checked
Nathaniel Alfred Alfred.Nathaniel at swx.com writes:
I think there is a memory leak in
http://svn.apache.org/viewcvs?rev=169806view=rev.
There is a strong reference session.wrappedSession from value to key in
// create new wrapper
session = new
In addition, I really don't like the implementation that was checked
in. Frankly, this is a case where I would look into leveraging
backport-util-concurrent
(http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) if that
code can be made to work in JDK 1.3.
What I would look to do
In addition, I really don't like the implementation that was checked
in. Frankly, this is a case where I would look into leveraging
backport-util-concurrent
(http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/) if that
code can be made to work in JDK 1.3.
What I would look to do
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Dienstag, 10. Mai 2005 18:56
To: dev@cocoon.apache.org
Subject: [IMP] synchronization on session object in Cocoon
As you can see on every request a new wrapper is instantiated
which is really
Joerg Heinicke wrote:
Hello,
I think I have found a more general problem with synchronization in Cocoon. I
tried to solve my problem with synchronization in flow script with an
intermediate object. This object handles the synchronized instantiation of my
component. Unfortunately I found out that
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.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Mittwoch, 11. Mai 2005 13:50
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
...
But the String pool comes to the rescue. This should work for all
Sylvain Wallez sylvain at apache.org writes:
I think I have found a more general problem with synchronization in Cocoon. I
tried to solve my problem with synchronization in flow script with an
intermediate object. This object handles the synchronized instantiation of my
component.
Nathaniel Alfred Alfred.Nathaniel at swx.com writes:
AFAIKS is the purpose of the existing synchronized(session) bits to
protect the consistency of the session object in case it is shared
between parallel executing requests.
Yes.
IIUC you need a lock object to really synchronize parallel
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Joerg Heinicke
Sent: Mittwoch, 11. Mai 2005 17:22
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
I have implemented the session attribute solution. Would be
nice if you can
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes:
I think I have found a more general problem with synchronization in Cocoon. I
tried to solve my problem with synchronization in flow script with an
intermediate object. This object handles the synchronized instantiation of my
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 11. Mai 2005 18:04
To: dev@cocoon.apache.org
Subject: Re: [IMP] synchronization on session object in Cocoon
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes:
Or more simply we could
Hello,
I think I have found a more general problem with synchronization in Cocoon. I
tried to solve my problem with synchronization in flow script with an
intermediate object. This object handles the synchronized instantiation of my
component. Unfortunately I found out that synchronized (session)
28 matches
Mail list logo
