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 is to add the wrapper to a Map using the session id as the key, and then add an attribute to the session that is an instance of a class that implements SessionBindingListener. Then when the sessionDestroyed method is called the wrapper can be removed from the Map.

Thus the Map would be the object being synchronized, such as
String id = serverSession.getId();
syncronized(map) {
   if (!map.contains(id)) {
       return (Session)map.get(id);
   }
   else {
       Session session = new HttpSession(serverSession);
       map.put(id, session);
       return session;
   }
}

Nathaniel Alfred wrote:

I have an implementation with map in HttpRequest and without "double-checked
locking idiom". Shall I commit it?


Joerg



I think there is a memory leak in http://svn.apache.org/viewcvs?rev=169806&view=rev. There is a strong reference session.wrappedSession from value to key in

                   // create new wrapper
                   session = new HttpSession(serverSession);
                   sessions.put(serverSession, session);

which causes the WeakHashMap to keep the entries forever.

See the Implementation Note in 
http://java.sun.com/j2se/1.4.2/docs/api/java/util/WeakHashMap.html.

Cheers, Alfred.





Reply via email to