You could do reattach objects with hibernateSession.lock( object, LockMode.NONE), but I suggest explicit reattaching with session.merge( object ). Explicit merging is better IMO because easily allows "wizard"-like multi iteration editing of an object and then persisting all the changes if desired.
With automatic reattaching all the changes will be persisted as user proceeds and it makes harder to cancel all those changes.... Anthony Fox <[EMAIL PROTECTED]> wrote: I have considered a similar solution as I use Spring as well. However, I was looking for a way to not have to _explicitly_ reattach objects. Rather, I would like all persistent detached objects in the session's context to reattach automatically. A filter or interceptor with knowledge of what objects are hibernate detached objects and reattached them automatically would be ideal. This would ease further development as adding new persistent properties to pages wouldn't need the additional step of adding these properties to the list of properties to reattach at pageRender time. Have you considered or seen a solution like the one I have described? On 2/22/06, Shawn Church wrote: > I'm doing this in several applications. I normally use Spring also, but > that is not really necessary. Tapestry isn't aware of the persistence > implementation, but it does have to explicitly attach (and occasionally > merge or evict) detached objects. Since I reference my DAO services in > my Tapestry pages already, it seemed appropriate to create a > "HibernateService" and "HibernateLegacyService" (I probably should have > named them something more generic) with public methods supporting > attach, merge, and evict. I have to support multiple, unrelated > databases, hence the multiple session-management implementations. I > only attach in pageBeginRender, although I occasionally have to merge or > evict in my form listener. > > I believe Tapestry is best suited to working with detached objects (and > this method is one which is recommended by the Hibernate team), rather > than storing IDs and reloading. In my case especially where I have a > lot of composite keys, passing IDs around would be a hack. Having the > detached object available to Tapestry makes it very nice and seamless > when I need access to collections or other objects within that object. > > I don't experience lazy initialization exceptions any more (unless I've > done something really wrong), but NonUniqueObjectExceptions can creep in > if for example I try to load an object which happens to already have > been loaded within the same session within a collection of a parent > object. This is again often the result of me doing something stupid, > but there a few (rare in my case) legitimate instances where this is > needed. In this case, I take care to first evict (or merge if > appropriate) the duplicate object. > > Shawn > > Quoting Anthony Fox : > > > Hi, > > > > I have an application that has a lot of hibernate detached objects > > (with lazy loaded collections) that are persistent page properties. > > What are best practices for reattaching these detached objects while > > maintaining a clean separation of layers? I have my implementation > > specific persistence layer separated into DAOs, a service layer, and > > the tapestry ui layer. I would like to keep tapestry independent of > > the persistence layer. I am using the OpenSessionInView pattern to > > open a new hibernate session for each web request. However, I can't > > determine a clean way to reattach all the hibernate detached objects > > at the beginning of each web request. I've noticed that some people > > use pageBeginRender() to reattach objects, but I don't want to > > expose > > my tapestry code to the persistence implementation. An interceptor > > or > > filter or something that separated the ui layer from being aware of > > the persistence layer would be ideal. How have others dealt with > > this > > issue? > > > > Thanks, > > Anthony > > > > --------------------------------------------------------------------- > > 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] Konstantin Ignatyev PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
