IHibernateDao uses a callback, IHibernateCallback. You can do anything
you like before you give out the session, and anything you like after
the callback has been executed.
On 8/13/05, Gili <[EMAIL PROTECTED]> wrote:
>
> I solved this with the following implementation inside my Page:
>
> private Session session;
>
> public void onBeginRequest()
> {
> HibernateHelper hibernate = HibernateHelper.getInstance();
> SessionFactory sessionFactory = hibernate.getSessionFactory();
> session = hibernate.openSession(sessionFactory);
> }
>
> public void onEndRequest()
> {
> HibernateHelper hibernate = HibernateHelper.getInstance();
> hibernate.closeSession(session);
> }
>
> private final IHibernateDao sessionProvider = new HibernateDaoSupport()
> {
> @Override
> public Session getSession()
> {
> return session;
> }
> };
>
> but... is this a hack? or is this the way I'm *supposed* to do this?
>
> Thanks,
> Gili
>
> Gili wrote:
> >
> > Why doesn't IHibernateDao contains a method used to close a Session?
> > It's all nice and well to be able to open a session but unless there is
> > a hook for closing a session we're going to be leaking resources. The
> > code seems to assume that closing a session is as simple as invoking
> > Session.close() but this is not necessarily true. In my code, for
> > example, I associate an Interceptor with a Session and store the
> > association in a Map. When certain exceptions are thrown, such as
> > StaleObjectStateException, I retrieve the Interceptor associated with
> > the session and use information stored within to roll back some changes
> > that Hibernate does not do itself.
> >
> > My point is this: unless IHibernateDao has a method like:
> >
> > closeSession(Session)
> >
> > then my code will leak resources. I could always use WeakReferences to
> > work around this but the problem remains: we should provide a hook for
> > closing a session. Also there seems to be a lack of correlation betwen
> > the request cycle and IHibernateDao. IHibernateDao should make some sort
> > of guarantees ... like, does it guarantee that the session returned by
> > getSession() will only be used within a single request and then
> > getSession() will be invoked in the next request? Without these sorts of
> > guarantees it becomes difficult to control the session life-cycle...
> >
> > Ideas?
> >
> > Gili
>
> --
> http://www.desktopbeautifier.com/
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
