Thanks for replies! I think the easier approach is to save the object ID in the session, as Szemere said. Someone has used tapestry-hibernate and knows what happens in this cases? it stores the real objetct in web session and then it merges with de new hib-session? thanks again
On Mon, Nov 16, 2009 at 2:36 AM, Jonathan Barker <jonathan.theit...@gmail.com> wrote: > This also depends on your objectives. > > If you have a detached entity in your session, then you have the option to > check for changes in the DB when you try to save, and then present some kind > of conflict resolution screen, rather than blindly overwriting or accepting > changes made in another session. Having said that, "blindly accepting / > overwriting" is usually fine for my applications and I *usually* store the > id. > > Jonathan > > > On Fri, Nov 13, 2009 at 9:18 AM, Szemere Szemere < > szemereszem...@googlemail.com> wrote: > >> Afaik any Hibernate object stored in the HTTPSession will be >> Hibernate-detached between HTTP requests. It is not refreshed/merged >> automatically on a new HTTP request, so it will be outside the Hibernate >> session on the second request which is probably not what you want. >> >> It is generally a much better idea to store the object id in the session >> and >> recreate it at the beginning of each new HTTP request. Tapestry has some >> features to make this easy for you, but that's beyond my expertise (search >> the mailing list). >> >> Szemere >> > > > > -- > Jonathan Barker > ITStrategic > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
