Latest thinking on hibernate session
Spring's Hibernate interceptors and FlushingSpringSessionInViewFilter are really incompatible. According to Hibernate manual "9.4.1 Updating in the same Session" and "9.4.2 Updating detached objects" UI's are more inclind to open/close session at DAO interface thus requiring save and flush methods. The FlushingSpringSessionInViewFilter would allow you to avoid having to write save/update methods which is cool in theory, but forms ought-not edit real business objects attached to session because they will get peristed on every form submit! Even worse a harmless query can trigger an automatic save (See javadoc on FLUSH_AUTO, I tested this and it does as it says).

Alternative include delegating every form input to business methods only when there's a ok/apply is maintenance nightmare as can be seen in PetStore sample app. Manually dettaching and attaching objects from session when a save is required is an approach but when you think about it, we've replace one simple call to save, with two calls to dettach then reattach. Where's the savings? Plus, calling save is more more natural.

So if we go back to open/closing session at DAO, lazy loaded references throw exceptions because they're no attached session. Which orignally lead me down the path to using FlushingSpringSessionInViewFilter. I'm inclined to solve this with an AOP interceptor for each method that requres lazy loading, right now only one, I may just hack it until I can get my head around Spring's AOP.
- posted by Unknown @ 5:24 AM | permalink