-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 11 posts ] 
Author Message
 Post subject: Long trans w/ reconnect issue - 2 simultaneous requests
PostPosted: Mon Nov 10, 2003 8:02 pm 
Regular
Regular

Joined: Tue Aug 26, 2003 7:53 pm
Posts: 66
Location: Lakeland, Florida USA
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);
               }
            }
         }
      }


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2003 8:14 pm 
Expert
Expert

Joined: Tue Sep 16, 2003 4:06 pm
Posts: 318
Location: St. Petersburg, Russia
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...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2003 8:20 pm 
Regular
Regular

Joined: Tue Aug 26, 2003 7:53 pm
Posts: 66
Location: Lakeland, Florida USA
URL's that apply are:
Code:
<filter-mapping>
<filter-name>hibernate</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 10, 2003 8:29 pm 
Expert
Expert

Joined: Tue Sep 16, 2003 4:06 pm
Posts: 318
Location: St. Petersburg, Russia
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?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 7:34 am 
Regular
Regular

Joined: Tue Aug 26, 2003 7:53 pm
Posts: 66
Location: Lakeland, Florida USA
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 8:09 am 
Expert
Expert

Joined: Tue Sep 16, 2003 4:06 pm
Posts: 318
Location: St. Petersburg, Russia
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 8:13 am 
Expert
Expert

Joined: Tue Sep 16, 2003 4:06 pm
Posts: 318
Location: St. Petersburg, Russia
factory.connect()

of course


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 8:29 am 
Regular
Regular

Joined: Tue Aug 26, 2003 7:53 pm
Posts: 66
Location: Lakeland, Florida USA
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 8:39 am 
Expert
Expert

Joined: Tue Sep 16, 2003 4:06 pm
Posts: 318
Location: St. Petersburg, Russia
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?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 8:43 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.

_________________
JAVA PERSISTENCE WITH HIBERNATE
http://jpwh.org
Get the book, training, and consulting for your Hibernate team.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2003 9:47 am 
Regular
Regular

Joined: Tue Aug 26, 2003 7:53 pm
Posts: 66
Location: Lakeland, Florida USA
whew, thanks christian. The only other idea we had was to store a counter, incrementing for ea reconnect and decrementing for each disconnect.

Jeff


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 11 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.