This would work in simple cases, but there are some problems. First, if foo references a lazy collection, the collection would not be accessible after the evict(). Also, LockMode.NONE can only be used if foo is not modified in any way.
So, if "Do some stuff" is simply "read some of foo's non-lazily-initialized properties", then everything is fine. If "Do some stuff" means "modify some of foo's non-lazily-initialized properties", then you would have to use session.merge(). In Hibernate 2.x, the method was "saveOrUpdateCopy()", but in Hib 3 that method is deprecated in favor of "merge()". If "Do some stuff" means "iterate foo's lazily-initialized collection", then you would have trouble since foo is no longer associated with an open session. You may also have some trouble with transaction-management issues (if you are concerned about dao transactions), which is another reason Spring has been helpful to me. With Spring, it is easy to define which types of service methods need which types of transactional support. For example, if you have a service method which needs to perform a set of operations as a unit (update this, delete that), Spring manages the details without requiring any special coding on your part. If you don't mind having Hibernate operations intermingled with your view-layer code, you might be able to get by without Spring. I prefer to keep them separate, so my pages can just request and store data without much regard for the lower-level details. I am no Hibernate or Spring expert, but I haven't found any other way that works 100% of the time. 95% is easy, but due to Hibernate's strict nature it has not been easy for me to find a 100% solution. I'm open to suggestions, but so far I'm pretty comfortable with this solution. If I ever get a lazy init exception or a duplicate object exception, I've most likely done something silly. Shawn Quoting Patrick Casey <[EMAIL PROTECTED]>: > > Can't you just re-attach with lock? > > e.g. > > Session first = Configuration.createSession(); > Object foo = first.get(Foo.class, 24); > first.evict(foo); > ... > Do some stuff > ... > > Session second = Configuration.createSession(); > Second.lock(foo, LockMode.NONE); > // you're now attached to second > > > > -----Original Message----- > > From: Shawn Church [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 18, 2005 9:57 AM > > To: Tapestry users > > Subject: Re: Hibernate+Spring: OpenSessionInViewFilter problem > > > > The problem with this is that it does not address the issue of > > reattaching detached objects to the currently-open session. Since > it is > > natural in Tapestry to instantiate an object, use it in a page, and > then > > to persist the (potentially) changed object, the object must first > be > > reattached to the Hibernate session. Even if the object is not > > persisted, if it contains lazy collection references it is > necessary to > > reattach the object in order for the collection to be properly > > initialized. > > > > The only reliable solution I have found is to use Spring's > > OpenSessionInView filter with singleSession=true, and then to > explicitly > > reattach objects in pageBeginRender(). I use a custom > HibernateService > > class which implements methods for attach(), evict(), and merge(). > The > > attach() method actually does a getSession().lock(object, > > LockMode.NONE), but it handles NonUniqueObjectExceptions which > will > > commonly be thrown when using lazy collections if one of the > collection > > objects happens to already exist in the session. > > > > Shawn > > > > Quoting Andreas Andreou <[EMAIL PROTECTED]>: > > > > > Regarding to not using servlet filters for the OpenSessionInView > > > approach, I can confirm that other approaches work! > > > First of all, > > > i've always used the HibernateUtil class posted in hibernate > forums > > > (and maybe also included in Hibernate in Action) that stores and > > > gets > > > session and transaction objects in thread local variables. > > > > > > So, opening a hibernate session is never a problem (whichever > method > > > first uses one, creates it) and so it only remains the issue of > > > closing it > > > somewhere. > > > > > > I haven't tried the cleanupAfterRequest() of Engine approach. > > > Instead i've always extended the > > > pageEndRender(PageEvent event) > > > in a BasePage (that all my pages extend) and there I just do: > > > > > > super.pageEndRender(event); > > > HibernateUtil.closeSession(); > > > > > > The nice thing is that this closeSession() never complains, no > > > matter > > > if no session is found, or if it has already been closed. > > > > > > Anyway, I can post the HibernateUtil class here if you want > to... > > > Andreas > > > > > > Alejandro Scandroli wrote: > > > > > > >Henry Chen wrote: > > > > > > > > > > > >>I have been searching around desperately for solution of > handling > > > >>lazy-loading database objects in tapestry. I configured > > > >>OpenSessionInViewFilter for Tapestry pages. It worked for some > > > cases > > > >>but not all. For example, in the table component, the first > page > > > was > > > >>good, but when I selected other pages, it gave me the > > > >>LazyInitialization exception - owning session was closed. Is > there > > > any > > > >>way around it now? Thanks a lot! > > > >> > > > >> > > > > > > > >Hi , I'm having the same problem on Trails. > > > >This quote may help. > > > > > > > >quote form Open Session in View discussion on Hibernate site. > > > ><quote> > > > >Open Session pattern and Tapestry web framework > > > >24 Mar 2004, 19:27 wassup > > > > > > > >If you develop your application with Tapestry framework it is > > > better > > > >do not use Servlet Filters to manage request cycle. More > preferable > > > to > > > >override setupForRequest() and cleanupAfterRequest() of Engine > > > >class. > > > ></quote> > > > > > > > >I have no time to try this. > > > >Please let me know if it works for you, or if you find another > > > workaround. > > > > > > > >Saludos. > > > >Alejandro. > > > > > > > >PD:- please, excuse my English. > > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > >For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
