There's a third approach you should definitely consider:
Never detatch your persistent objects and use a long session. It'll
prevent all those nasty dirty collection, uninitialized collection, and lazy
initialization problems.
The downside is that every time a page submits, it writes "live"
into your persistent object which will write through the next time the
session flushes so you have to be careful about that.
Also, make sure you use temp sessions for large queries so as not to
pollute your "long" session with lots of persistent objects it doesn't
really need.
--- Pat
> -----Original Message-----
> From: Peter Ertl [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 22, 2005 10:50 AM
> To: Tapestry users
> Subject: RE: Another Stupid Hibernate Question (TP4)
>
> you sound like a happy hibernate user, so I hope I
> can bother you with a question:
>
> do you use detached instances as @Persist-ent properties and
> reattach them using
>
> session.lock(entity, LockMode.NONE)
>
> or do you serialize the business key only and restore the entities with
>
> session.get(type, key)
>
> ?
>
> I got little luck with session.lock(...) inside forms that manipulate the
> state of a hibernate object, especially if I modify collections as
> hibernate states I 'can not reattach objects with a dirty collection'.
>
> you answer would be of great help as hibernate
> gives me an incredible hard time. And I just don't want to
> write SQL myself :-)
>
>
> regards
> Peter
>
> > --- Ursprüngliche Nachricht ---
> > Von: "Kurtis Williams" <[EMAIL PROTECTED]>
> > An: "Tapestry users" <[email protected]>
> > Kopie: <[EMAIL PROTECTED]>
> > Betreff: RE: Another Stupid Hibernate Question (TP4)
> > Datum: Thu, 22 Sep 2005 10:18:48 -0600
> >
> > I've successfully deployed several Tapestry/Hibernate applications using
> > Spring as the glue. Personally, I find Hibernate development is made
> > easier with Spring, even in small projects. I can't imagine using
> > Hibernate without using Spring. The two work hand-in-glove. Spring's
> > declarative transaction handling alone is worth the price of admission.
> >
> > As for the OpenSessionInView filter provided with Spring, it works great
> > with Tapestry applications.
> >
> > Most folks run into problems with Tapestry and Hibernate because they're
> > not careful with lazy properties and detached objects. With Tapestry's
> > wealth of options for dealing with object data in a page it's very easy
> > to get your hibernate objects detached from a session. That can cause
> > the two exceptions everybody encounters (and unfairly blames on the
> > Hibernate/Tapestry combo):
> >
> > The infamous net.sf.hibernate.LazyInitializationException
> > And the insidious net.sf.hibernate.NonUniqueObjectException
> >
> > These two problems are easily solved by using the OpenSessionInView
> > pattern and by carefully managing when and where objects are serialized
> > into either the Session (as persistent properties) or the Page (as
> > hidden fields, parameters, etc. - use "View Source" to make sure there
> > aren't unexpected hibernate serializations into your page.)
> >
> > -----Original Message-----
> > From: Cory Watson [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, September 17, 2005 9:20 PM
> > To: Tapestry users
> > Subject: Another Stupid Hibernate Question (TP4)
> >
> > I can't find a definitive answer for how to utilize Hibernate
> > properly in Tapestry.
> >
> > I used to use a 'Session In View' by way of a HibernateHelper class
> > with that held the session in a ThreadLocal, then utilized my
> > Engine's cleanupAfterRequest(). This suddenly no longer works right
> > in TP4. My cleanupAfterRequest() never gets called.
> >
> > I see custom services, hivetranse, spring, and servlet filters. I
> > realize that all of these probably have their place, but I don't
> > understand which one is good for me. I'm a bit leery of using Spring
> > for something this simple, and the hivemind ways scare me because i
> > only see whispers of it and no examples that help me understand how
> > to do it.
> >
> > So help a guy out. What's the best way to accomplish the proper
> > session.close() and session.flush() at the end of a request? That's
> > all I'm after. For now I'll use a servlet filter.
> >
> > Cory Watson
> > http://www.onemogin.com
> >
> >
> > ---------------------------------------------------------------------
> > 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]
