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: [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]
