Requestfactory спящего режима сеанса за просьбу

Question

Я пытаюсь обновить приложение для использования сеанса каждого запроса шаблона, так что я могу перейти на более новые версии GWT (мои объекты не спасают правильно пройти 2,4 - GWT >2.4 RequestFactory not saving child object changes

Я реализовал фильтр запросов, и, похоже, он работает правильно - я могу не доводить данные до клиента. Однако, когда я пытаюсь сохранить объект, он выдает ошибку, поскольку он не находит активную транзакцию:

org.hibernate.HibernateException: saveOrUpdate is not valid without active transaction 

Я вытащил большую часть информации о том, как реализовать этот шаблон от https://developer.jboss.org/wiki/OpenSessionInView. Вот мой фильтр:

public class HibernateSessionRequestFilter implements Filter { 

private static Log log = LogFactory.getLog(HibernateSessionRequestFilter.class); 

private SessionFactory sf; 

public void doFilter(ServletRequest request, 
        ServletResponse response, 
        FilterChain chain) 
     throws IOException, ServletException { 

    try { 
     System.out.println("Starting a database transaction"); 
     sf.getCurrentSession().beginTransaction(); 

     // Call the next filter (continue request processing) 
     chain.doFilter(request, response); 

     // Commit and cleanup 
     System.out.println("Committing the database transaction"); 
     sf.getCurrentSession().getTransaction().commit(); 

    } catch (StaleObjectStateException staleEx) { 
     log.error("This interceptor does not implement optimistic concurrency control!"); 
     log.error("Your application will not work until you add compensation actions!"); 
     // Rollback, close everything, possibly compensate for any permanent changes 
     // during the conversation, and finally restart business conversation. Maybe 
     // give the user of the application a chance to merge some of his work with 
     // fresh data... what you do here depends on your applications design. 
     throw staleEx; 
    } catch (Throwable ex) { 
     // Rollback only 
     ex.printStackTrace(); 
     try { 
      if (sf.getCurrentSession().getTransaction().isActive()) { 
       System.out.println("Trying to rollback database transaction after exception"); 
       sf.getCurrentSession().getTransaction().rollback(); 
      } 
     } catch (Throwable rbEx) { 
      log.error("Could not rollback transaction after exception!", rbEx); 
     } 

     // Let others handle it... maybe another interceptor for exceptions? 
     throw new ServletException(ex); 
    } 
} 

public void init(FilterConfig filterConfig) throws ServletException { 
    System.out.println("Initializing filter..."); 
    System.out.println("Obtaining SessionFactory from static HibernateUtil singleton"); 
    sf = HibernateUtil.getSessionFactory(); 
} 

public void destroy() {} 

} 

Мой web.xml:

<servlet> 
    <servlet-name>requestFactoryServlet</servlet-name> 
    <servlet-class>com.example.server.util.ExampleRequestFactoryServlet</servlet-class> 
    </servlet> 

    <servlet-mapping> 
    <servlet-name>requestFactoryServlet</servlet-name> 
    <url-pattern>/gwtRequest</url-pattern> 
    </servlet-mapping> 

    <filter> 
     <filter-name>HibernateFilter</filter-name> 
     <filter-class>com.example.server.util.HibernateSessionRequestFilter</filter-class> 
    </filter> 

    <filter-mapping> 
     <filter-name>HibernateFilter</filter-name> 
     <url-pattern>/gwtRequest</url-pattern> 
    </filter-mapping> 

сохраняемый очень проста:

// client 
private void saveScale(ScaleProxy scale) { 
    scaleRequest.save(scale) 
    .fire(new Receiver<Void>() { 
     @Override 
     public void onSuccess(Void response) { 
      Window.alert("Scale saved."); 
     }   
    }); 
} 

// server 
public static void save(Scale scale) { 
    Session session = HibernateUtil.getSessionFactory().getCurrentSession(); 

    session.saveOrUpdate(scale); 
} 

Любая другая информация, я могу предоставить? Я ценю любые идеи или идеи!

Answer 1

Для каждого запроса требуется один сеанс, но не одна транзакция. Открывать и закрывать транзакции в каждом методе службы для правильного поведения в случае ошибки.