I am moving forward with integrating Hibernate and Tapestry, and I have now added Spring into the mix. I've eliminated lazy initialization exceptions (so far, thanks to OpenSessionInViewFilter), but I'm now trying to establish a set of best practices for working with detached objects.

Without going into all the Tapestry-specific mechanics, I am loading an object graph (ie - Cat, one-to-many with Kittens), and handing Cat to my Tapestry controller. The kitten list is shown, and one is selected for editing. Tapestry handles all the serialization / deserialization of the Kitten in question, and eventually I am ready to persist the edited Kitten object.

This last step is where I am unsure of the best method. My Hibernate mappings are set to cascade save-update, and I would like to update the Kitten (along with any other updates which may have been made to Cat) with getCatService().save( getCat()).

Since the original kitten instance would have been serialized and deserialized, I need to reassociate the detached Kitten with the Cat object graph. It works fine to explicitly save the Kitten (ie getKittenService().save( getKitten()), but I have to be careful not to save the Cat without first re-fetching the kitten list. This also doesn't take full advantage of Hibernate's cascading update.

Can anyone recommend the best way to accomplish this? I could just fetch the persisted Cat.kittenList, delete the one (by id) I have just edited, add the edited one back to the Cat.kittenList, and save Cat, but that seems like a silly amount of work for such a simple case.

I also realize there are other/better ways of performing the above sequence, but since this exploits Tapestry's capabilities I would like to find a clean way of implementing this.

Thanks