I've never tried using HiveTrans, so I can't comment on that. If you
use my helper class, it does two things for you:
A) For a given user, every data request will use the same Hibernate
session. So you can load an object on one page, and then ten minutes later
work with its lazily initialized sets and all will be well.
B) Each user gets one and only one session. Session creation is
moderately expensive so using a single session (instead of, for example,
creating a new session for each DB interaction) is much more efficient.
To actually work with the session though you need to get it e.g.
Session s = HibHelper.getSession()
This isn't creating a new session though, it's just returning you a
handle to your user's personal Hibernate Session which persists between
requests.
Then you use the Session normally (because it is a normal Session).
You *do not* need to worry about closing it because it stays open; that's
the whole point of the long session pattern. So a typical use case would be:
Session s = HibHelper.getSession();
Foo o = s.load(Foo.class, id);
o.setSomeField(bar);
// if you do nothing else, bar foo will be saved to the DB on the
next automatic flush
// if you want to persist the changes ot foo *right now* you can do
s.flush();
// you do not need to call s.close()
> -----Original Message-----
> From: Chris Chiappone [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 1:48 PM
> To: Tapestry users
> Subject: Re: Transaction handling. Where?
>
> Thanks, if I were to use this helperclass would I still go about
> getting the session before a save or update and closing the session
> after complete, as i was before?
>
> Also have you thought about using something like HiveTrans to do this
> for you? I have been thinking about moving to tap 4 and using
> hivemind with hivetrans to deal with the hibernate session management.
> Any thoughts??
>
> On 8/30/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> >
> > To be honest, I *haven't* completely gotten around this problem.
> > I've *sort of* gotten around it by going to a long-session pattern so
> that
> > the Hibernate session virtually never flushes. If you want though I'll
> > attach my HibHelper class so you can get a feel for what I did.
> >
> > Honestly though, it's not a magic bullet and I'm still struggling
> to
> > find one. Still, if it gets you partway there, you're welcome to use it,
> > modify it, whatever.
> >
> > To use it effectively you'll need a combination of the HibHelper
> > class (above) and the subclassed engine I provided earlier which stores
> and
> > retrieves the Hibernate session from the user session.
> >
> > --- Pat
> >
> > > -----Original Message-----
> > > From: Chris Chiappone [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, August 30, 2005 1:40 PM
> > > To: Tapestry users
> > > Subject: Re: Transaction handling. Where?
> > >
> > > I was search back some threads and noticed your HibHelper class. Is
> > > that basically the way you've gotten around this problem, HibHelper
> > > and the Servlet class you wrote?
> > >
> > > On 8/30/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Not necessarily, but it depends on how you want your system
> to
> > > > manage transactions. One area where Hibernate and Tapestry don't
> "play
> > > nice"
> > > > is with data binding.
> > > >
> > > > Let's say I have a "user" form that is bound to a persistent
> User
> > > > object.
> > > >
> > > > Form gets rendered and goes out.
> > > > User does some stuff and presses save.
> > > > Form comes in, rewinds, and delta is pushed through into
> "user"
> > > > object.
> > > > *** At this point the user object is flagged by Hibernate as
> > > dirty.
> > > > The next time the session flushes, it'll write through to the
> database,
> > > > whether or not you call saveOrUpdate()!
> > > >
> > > > This is problematic if, for example, you want to cancel the
> > > update
> > > > because of failed validations :(.
> > > >
> > > > One approach that can help is to evict everything from the
> > > session
> > > > on load so that it doesn't auto-flush. If you do this though, you
> will
> > > > likely have lazy initialization problems later on.
> > > >
> > > > Another approach is to not directly bind your page to your
> > > > persistent object, but that adds a whole other level of work to the
> page
> > > > class.
> > > >
> > > > All in all, I have not been happy with the interaction
> between
> > > > Hibernate and Tapestry. With a classic servlet engine it's not a
> biggy
> > > > because you can just not push invalid updates into the persistent
> > > object.
> > > > With Tapestry though, the (normally helpful) behavior of directly
> > > binding
> > > > user updates into the underlying persistent object doesn't allow the
> > > > programmer any control over when updates go through.
> > > >
> > > > Basically it all comes down to Hibernate insisting that it
> knows
> > > > better than the programmer when things ought to be saved to the DB
> :(.
> > > >
> > > > --- Pat
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Chiappone [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, August 30, 2005 1:07 PM
> > > > > To: Tapestry users
> > > > > Subject: Re: Transaction handling. Where?
> > > > >
> > > > > In my DOA i do the following...
> > > > >
> > > > > public void makePersistentUser(Users user)
> > > > > throws InfrastructureException {
> > > > >
> > > > > try {
> > > > > HibernateUtil.beginTransaction();
> > > > >
> HibernateUtil.getSession().saveOrUpdate(user);
> > > > > HibernateUtil.commitTransaction();
> > > > > HibernateUtil.closeSession();
> > > > > } catch (HibernateException ex) {
> > > > > throw new InfrastructureException(ex);
> > > > > }
> > > > > }
> > > > >
> > > > > Is this the wrong way to do it??
> > > > >
> > > > > On 8/30/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Have you tried subclassing BaseEngine and doing your
> > > transaction
> > > > > > management in cleanupAfterRequest() and setupForRequest() e.g.
> > > > > >
> > > > > > public class CorinnaEngine extends BaseEngine {
> > > > > > private static final long serialVersionUID =
> > > > > 3257284742721648952L;
> > > > > >
> > > > > > protected void cleanupAfterRequest(IRequestCycle cycle) {
> > > > > > HibHelper.cleanupSession();
> > > > > >
> > > > > > super.cleanupAfterRequest(cycle);
> > > > > > }
> > > > > >
> > > > > > protected void setupForRequest(RequestContext context) {
> > > > > > HttpSession hs = MyServlet.getCurrentSession();
> > > > > > HibHelper.attachSession(hs);
> > > > > > HibHelper.getSession();
> > > > > > super.setupForRequest(context);
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > }
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Koka [mailto:[EMAIL PROTECTED]
> > > > > > > Sent: Tuesday, August 30, 2005 12:00 PM
> > > > > > > To: [email protected]
> > > > > > > Subject: Transaction handling. Where?
> > > > > > >
> > > > > > > Well, I have pages that allow to edit some database data, so I
> > > have
> > > > > easy
> > > > > > > solution to start transaction at
> > > > > > > public void pageBeginRender(PageEvent event)
> > > > > > > {
> > > > > > > if (event.getRequestCycle().isRewinding())
> > > > > > >
> > > > > > > // start transaction here
> > > > > > > }
> > > > > > >
> > > > > > > and at
> > > > > > > public void pageEndRender(PageEvent event)
> > > > > > > {
> > > > > > > if (event.getRequestCycle().isRewinding())
> > > > > > > {
> > > > > > > // Commit or rollback if errors found
> > > > > > >
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > Hmm, it WORKS fine but, hmmm, page render and transactions...,
> > > agrrr
> > > > > sure
> > > > > > > there's some other place to handle things.So the question is
> what
> > > is
> > > > > the
> > > > > > > right place to start/end transaction in Tap4
> > > > > > > TYA
> > > > > >
> > > > > >
> > > > > >
> > > > > > ----------------------------------------------------------------
> ----
> > > -
> > > > > > To unsubscribe, e-mail: tapestry-user-
> [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: tapestry-user-
> > > [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ~chris
> > > > >
> > > > > ------------------------------------------------------------------
> ---
> > > > > To unsubscribe, e-mail: tapestry-user-
> [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: tapestry-user-
> [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------------------
> -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: tapestry-user-
> [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > > --
> > > ~chris
> > >
> > > ---------------------------------------------------------------------
> > > 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]
> >
> >
> >
>
>
> --
> ~chris
>
> ---------------------------------------------------------------------
> 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]
