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
