Long trans w/ reconnect issue - 2 simultaneous requests

jwboring · **Posted:** Mon Nov 10, 2003 8:02 pm

How are others handling the situation were a user sends a request in and before that request can finish, causes another request to be sent? We are using long transactions with reconnect and have a filter doing the dis/re-connecting. Our stop gap solution was to synchronized the filter (see code below), including the chain.doFilter. Obviously, we need a better solution. Thanks for any help,

Jeff

Code:

      try {
         synchronized (request.getSession()) {
            ThreadObjectManager threadObjectManager =
               SessionFactoryUtils.getThreadObjectManager();

            if (threadObjectManager.hasThreadObject(sessionFactory)) {
               threadObjectManager.removeThreadObject(sessionFactory);
            }

            Session session =
               (Session) request.getSession().getAttribute(
                  HIBERNATE_SESSION_KEY);

            if (session != null) {
               session.reconnect();
            } 
            else {
               session = sessionFactory.openSession();
               request.getSession().setAttribute(
                  HIBERNATE_SESSION_KEY,
                  session);
            }

            threadObjectManager.bindThreadObject(
               sessionFactory,
               new SessionHolder(session));

            try {
               chain.doFilter(request, response);
            } finally {
                  try {
                     session.disconnect();
                  } 
               catch (HibernateException e) {
                  log.warn(e);
               }
            }
         }
      } 

dimas · **Posted:** Mon Nov 10, 2003 8:14 pm

Wow!
Do you youse thif filter on specific URL or just on /* ?
In the latter case, as I understans your server just can not execute ANY two requests from the same user in parallel. If images and other static content is also served by this server, it is very bad idea I think...

jwboring · **Posted:** Mon Nov 10, 2003 8:20 pm

URL's that apply are:

Code:

<filter-mapping>
<filter-name>hibernate</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>

dimas · **Posted:** Mon Nov 10, 2003 8:29 pm

So they apply to Struts actions only, right? This is not that bad as I thought in the beginning :) but I still see no point in doing this. That means if user manages somehow to start a long operation (3 minutes for example) he will not be able to do ANYTHING meaningful in the same session. Imagine user will press "back" couple of times and try to "refresh" something. If that "something" was generated by Struts action (that means it matches *.do pattern), this operation will immediately hang for 3 minutes.

From user's point of view it looks like server just died. Or browser just dies. If user thinks it is browser, he just closes this one (abandons his session) and opens new one. 20 seconds later he will repeat the same long-running action. And now you have two long transactions and frustated user...

What was the original intent?

jwboring · **Posted:** Tue Nov 11, 2003 7:34 am

Its very simple. A user sends a request in and before that request can finish, causes another request to be sent either by e.g., click a link or back browser. Hibernate throws an exception on the reconnect (can't reconnect to a session that's already connected) without the synchronized. You can check the session.isConnected but that only delays the problem until disconnect.

Jeff

dimas · **Posted:** Tue Nov 11, 2003 8:09 am

Why don't you just open another session for another request? This is cheap.

You may use Thread Local pattern.

In out web application, filter is responsible for opening session in the beginning and rolling back uncommited changes at the end of the request. The opening is lazy - I mean session.connect() is not executed until the session is needed.

dimas · **Posted:** Tue Nov 11, 2003 8:13 am

factory.connect()

of course

jwboring · **Posted:** Tue Nov 11, 2003 8:29 am

We are using the Thread Local pattern and as I said in the first post, we are using long transactions with reconnect. Are you suggesting that reconnect doesn't work?

Jeff

dimas · **Posted:** Tue Nov 11, 2003 8:39 am

Hmmm...
To be honest, I do not understand why you use ThreadLocal in your code at all. Because in your example Hibernate session is bound to HTTP session not to a ThreadLocal varable.

I'm just asking why you are trying to keep the same Hibernate session for each request from the same user? Wouldn't it be easier to create new session for each request?

christian · **Posted:** Tue Nov 11, 2003 8:43 am

He uses both the HttpSession with disconnect/reconnect for "inactive" Sessions and an active Session is stored per thread in a ThreadLocal. His problems are real and I don't have a solution. Long Sessions are really not that easy to deal with and have various tradeoffs. I think we have to add that one.

jwboring · **Posted:** Tue Nov 11, 2003 9:47 am

whew, thanks christian. The only other idea we had was to store a counter, incrementing for ea reconnect and decrementing for each disconnect.

Jeff