Is a Servlet-Filter which serializes requests in the same user session ok?

Question

The Servelt specification states that the Web-Application is itself responsible for synchronizing access to HttpSessions. It is from the serversite not possible to prevent multiple threads to access the same HttpSession (i.e. the user could always open a second window, retransmit a form etc). My assumption is that while this does not happen often it can happen and therefore I think each access to the HttpSession must be synchronized. For a further discussion see http://forum.java.sun.com/thread.jsp?forum=4&thread=169872 .
Concurrent programming is generally complicated and errorprone. At least in developing JSPs it is inconvenient and easy to forget. My Web-App uses often HttpSession and it can be used in different not predefined places, so I had the idea to implement a ServletFilter which serializes threads which happen in the same session. This involves certainly some overhead. However for the advantages of easier code maintains and higher consistency I am ready to pay this overhead.
My question is generally what you think of this approach and second whether the way I implemented the Filter works.
The Filter actually generates for each Request an HttpServletRequestWrapper which intercepts calls to getSession and on call aquires a Lock so that other threads have to wait for the same Session. The lock is released when the doFilter method of the Filter returns. So threads run concurrently until the first access to the Session and from there they are serialized until the end of the Request.
For the details I will give the code for the Filter and the Wrapper (that?s all the code needed except the ReentrantLock which is Doug Lea?s implementation http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html )
the Filter
public class SessionThreadFilter implements Filter
  public static final String MUTEXT_IN_SESSION_KEY = "org.jaul.filter.SessionThreadFilter.MUTEX";
  //constructor, init, destroy methods do nothing
  public void doFilter(ServletRequest reqIn,ServletResponse res,FilterChain filterChain)
    throws IOException, ServletException
    //if req not instanceof of HttpRequest don't do anything
    if (!(reqIn instanceof HttpServletRequest))
      filterChain.doFilter(reqIn, res);
    } else
      HttpServletRequest req = (HttpServletRequest) reqIn;
      //We use a HttpRequestWrapper each time a user accesses
      //through this
      //Wrapper a Session is Lock is aquired. The filter method returns
      //the lock if it exists is released
      //each thread needs it's own wrapper so the wrapper itself
      //doesn't have to be synchronized
      SessionThreadRequestWrapper wrapper = new SessionThreadRequestWrapper(req);
      try{
        filterChain.doFilter(wrapper, res);
      }finally{
        ReentrantLock lock = wrapper.getLock();
        if (lock != null && lock.holds() != 0)
                   lock.release(lock.holds());
the Wrapper
final public class SessionThreadRequestWrapper extends HttpServletRequestWrapper {
  private ReentrantLock lock = null;
   * Constructor for SessionThreadRequestWrapper.
   * @param arg0
  public SessionThreadRequestWrapper(HttpServletRequest req){
    super(req);
   * @see javax.servlet.http.HttpServletRequest#getSession()
  public HttpSession getSession(){
    return getSession(true);
   * @see javax.servlet.http.HttpServletRequest#getSession(boolean)
  public HttpSession getSession(boolean construct){
    //this will get the session an the lock
    HttpSession session = getLockFromSession(construct);
    if (session == null) return null;
    //get a lock on the mutex
    try{
      lock.acquire();
    } catch (InterruptedException e){
      throw new IllegalStateException("Interrupted while thread waiting for session");
    //now we check again if the session is still valid
    try{
      session.getAttribute(SessionThreadFilter.MUTEXT_IN_SESSION_KEY);
    } catch (IllegalStateException e){
      //again we go recusively but first release the lock
      lock.release();
      lock = null;
      return getSession(construct);
    //after you got the lock you can return the session
    return session;
   * gets the lock from the session
   * @param construct
   * @return HttpSession
  private HttpSession getLockFromSession(boolean construct){
    //test if it is a new Session
    HttpSession session = super.getSession(construct);
    //if is null no session was realy requested
    if (session == null) return null;
    //otherwise try to get the lock if necessery construct it
    //syncrhonized over session
    synchronized (session){
      //this migth throw an Exception if the session has been
      //invalidated in the mean time
      try{
        lock = (ReentrantLock) session.getAttribute(SessionThreadFilter.MUTEXT_IN_SESSION_KEY);
        if (lock == null){
          lock = new ReentrantLock();
          session.setAttribute (SessionThreadFilter.MUTEXT_IN_SESSION_KEY, lock);
        return session;
      } catch (IllegalStateException e){
        //the session has been invalidated before we tried to get the
        //lock we recursively call getLockFromSession
        //( assumption checked with Jetty: if the session is invalidated
        //and getSession is called on the thread a new valid session
        // should is returend)
        //I hope sometime you should get a valid session but I am not
        //sure. This is crucial for breaking of the recursion
        lock = null;
        return this.getLockFromSession(construct);
  /** used by the Filter to get the lock so that it can release it
  ReentrantLock getLock(){
     return this.lock;
}As stated I would be very thankful if you could check the code and give some commends.

Answer 1

synchronized (session){Are you sure that the session instance returned by two
concurrent calls to getSession(...) are the same? I
think that tomcat for instance may return different
instances for the same "logical " session, which would
break your scheme I think... Thank you (I did not know that on Tomcat). The same thing could also occur if another filter wrapped the Session.
That's indeed a problem,which I have already adressed in another thread, but did not get an answer. ( http://forum.java.sun.com/thread.jsp?forum=33&thread=412380). The already cited thread http://forum.java.sun.com/thread.jsp?forum=4&thread=169872 adresses the same problem, but the discussion there ends with the recomandation that you should synchronize on HttpSession as I did it. Also in other forums I've read so.
However like you I've at least strong doubts in this approach, so now my question is on what should I than generally for any access in any web-app syncrhonize the access to Http-Session as demanded by the Servlet specs.
A few not realy satisfying answers:
Synchronize on the HttpSession itself: I think still the best approach, but as you say is it guaranteed that the same instance of an HttpSession is given to each Request (in one Session)?
Synchronized on the HttpServlet: This only works if no other servlet (or jsp) accesses in the session the value with the same key ( of course only if the session itself is threadsave). In case of ThingleThread it is not possible at all there can be multiple instances (you could use a static variable)
Holding the object to synchronize on in applicaton scope or session scope: This obiously doesn't help, because somehow you have to obtain the lock and at least there you need another synchronize.Holding in application socpe is slow a static variable lock would be better there.
Synchronize on some static variable: This will work, but is very slow (each request not only in the same session would synchronize on this).
Hold a map in application scope, which holds for each Session-key a lock: Is probably faster than the static variable thing. However the access and the management of the Map (removing of unused locks etc.- Mabe you could use a WeakHashMap to collect the locks for not used keys anymore) is time consuming too and again the map must be accessed syncrhonasly by all requests.
Syncrhonize on the Filter (only in my case): This is as slow as the static variable approach because each request will use the same lock the one instance of the Filter.
So synchronizing on the session is propably the best approach if the same attribute name is accesed by different servlets. However if you say that some Web-Containers return different HttpSession instances for the same Session (which is legal according to the specification) this of course does not work.
So I have realy no clue on what to syncrhonize than. Now help is not only neede on my Thread serialization filter but on my generally Servlet prgromming.
May be you could help me for another synchronization aproach.