|
From: Les A. H. <le...@ha...> - 2005-11-21 13:37:25
|
Sorry, I didn't get to finish my previous email (hit shortcut key for
'send' by accident).
It is not recommended to implement this type of behavior in a Hibernate
application. An application-transaction is scoped to a few connected
request/response cycles and shouldn't be used across a user's entire
interaction with the system - doing otherwise creates much greater
conflict for stale data and versioning conflicts.
Also, I'm not sure why you'd want to do this in the first place -
sessions are extremely lightweight objects that are meant to be created
and destroyed at the beginning and end of a single request,
respectively. They are only meant to be disconnected/reconnected across
multiple requests when those requests are related to what Hibernate
calls an "application transaction": when visiting multiple pages in
succession build up data context and that accumulated data should be
commited or rolled back at the same instant of time - think of a
web-based wizard, where at the end of step 4, only then should
everything be committed to the database.
If you're trying to enhance performance of the application (and
Hibernate is the only process accessing the database), it is more
efficient and better form to enable a 2nd-level cache (instead of using
the Session itself for that purpose).
From the Hibernate documentation:
"This pattern [long-lived session] is problematic if the Session is too
big to be stored during user think time, e.g. an HttpSession should be
kept as small as possible. As the Session is also the (mandatory)
first-level cache and contains all loaded objects, we can probably use
this strategy only for a few request/response cycles. This is indeed
recommended, as the Session will soon also have stale data."
Regards,
Les
P.S. I should also note that storing a Hibernate Session in an
HttpSession will cause problems in a clustered environment - its usually
better to maintain a stateless programming paradigm across the entire
application and enable the second cache if you ever envision software
being run in a clustered and/or striped deployment.
On Sun, 20 Nov 2005 20:29:21 -0500, "Artem Ploujnikov"
<bla...@ca...> said:
> Some Web application frameworks like JSF might require you to extend
> the
> lifetime of a persistent entity beyond a single HTTP request. What I am
> proposing is an alternative implementation of OpenSessionInViewFilter
> that
> opens one Hibernate session per HTTP session instead of one session per
> request. JDBC connection management should not be a problem because it is
> possible to disconnect and reconnect Hibernate sessions without closing
> them.
>
> Here is the filter that I'm using in my application... I think it would
> be a
> good idea to include something similar in a future release of Spring.
> Please
> note that it hasn't been well tested, and it requires a session filter
> that
> closes orphaned sessions.
>
> public class HibernateSessionFilter extends OncePerRequestFilter {
> public static final String DEFAULT_SESSION_FACTORY_BEAN_NAME =
> "sessionFactory";
> public static final String SESSION_KEY = "org.foo.web.hibernateSession";
>
> private String sessionFactoryBeanName =
> DEFAULT_SESSION_FACTORY_BEAN_NAME;
>
> /**
> * @return Returns the sessionFactoryBeanName.
> */
> protected String getSessionFactoryBeanName() {
> return sessionFactoryBeanName;
> }
>
>
> /**
> * @param sessionFactoryBeanName The sessionFactoryBeanName to set.
> */
> public void setSessionFactoryBeanName(String sessionFactoryBeanName) {
> this.sessionFactoryBeanName = sessionFactoryBeanName;
> }
>
>
> protected SessionFactory lookupSessionFactory() {
> if (logger.isDebugEnabled()) {
> logger.debug("Using SessionFactory '" + getSessionFactoryBeanName() +
> "'
> for OpenSessionInViewFilter");
> }
> WebApplicationContext wac =
> WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext());
> return (SessionFactory) wac.getBean(getSessionFactoryBeanName(),
> SessionFactory.class);
> }
>
> protected void doFilterInternal(
> HttpServletRequest request, HttpServletResponse response, FilterChain
> filterChain)
> throws ServletException, IOException {
> SessionFactory sessionFactory = lookupSessionFactory();
> HttpSession httpSession = request.getSession();
> Session session =
> (Session) httpSession.getAttribute(SESSION_KEY);
> if (session == null) {
> session = sessionFactory.openSession();
> httpSession.setAttribute(SESSION_KEY, session);
> }
> if (!session.isConnected()) {
> session.reconnect();
> }
> TransactionSynchronizationManager.bindResource(sessionFactory, new
> SessionHolder(session));
> try {
> filterChain.doFilter(request, response);
> } finally {
> TransactionSynchronizationManager.unbindResource(sessionFactory);
> session.disconnect();
> }
>
> }
>
> }
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|