Hi,

as a newbie of Hibernate and ORM in general I would need to have the behaviour of entity persistance and OpenSessionInView clarified.

I understand that:

- openSessionInViewFilter mantains the same session opened for the lifecycle of the request.

- according to the documentation, I understand that within the same hibernate session objects are persisted automatically, which means with no need to call a persist method (update(), saveOrUpdate(), ..) of the session.

in an environment with openSessionInViewFilter configured I would then call:


and at the end of the request:

myObj would be updated and someCollection would be updated with the new and modified collectionObject

all with no need of touching the session or call a saveOrUpdate().

Is that true?

If it is I wonder about using this pattern in a classic service/DAO configuration:

I have:



either from my service components or directly from the presentation layer (remembering I am using the OpenSessionInViewFilter), I can then do the following:

in struts (or whatever)

and magically myObj would be already saved on DB!?

no need to call at the end myDAO.persistMyObject (myObj)??

persist methods ould be then used ONLY across different requests when reattaching entities to hibernate?

This basically is my question, any help appreciated.

Thanks

Francesco[/code]

So long as the transaction is committed and the session flushed at the end of the view, yes. IIRC the default code (posted elsewhere on this site) does not commit/flush automatically, it requires your application code to do it. If you want to let the presentation layer do some business logic (usually a bad idea...) then you'll have to add the commit/flush code to the filter code.

Dear fran_tuma,

As a relative ORM newbie, I struggled with this question for a while as well. In the end I decided not to leave it up to OSIV to execute my db changes. In fact I've configured my OSIV interceptor never to flush. The effect of this is that db changes only occur when I explicitly tell my DAO to make them.

I prefer this approach because:
- it minimises coupling between my application tiers, e.g. I can change a single DAO to use JDBC or whatever instead of Hibernate, and the other layers won't be impacted. Even if you never intend to change your persistence technology, decoupling your application layers is a good design habit, e.g. it minimises the impact of changes and makes your code more testable.
- the code is more maintainable by my colleagues, who can see where the saves explicitly happen
- my unit tests can verify that my DAOs' save methods are called with the right data at the right time
- I was getting unexpected db changes, so turning off the auto flushing gave me confidence that this would never happen again. Even if I eventually find out what the cause was, I would still not go back because of all the reasons listed above.

In summary, using a traditional DAO pattern (i.e. one that includes explicit updates) lets you enjoy the main benefit of OSIV (i.e. lazy-loading) without any of the drawbacks or gotchas.

Hope this helps (and please rate if it did!),

Andrew

thanks to tenwit and andrew,

actually I agree with both and understand your points. What I think is the main issue is leaving the view indipendent from ubderlying persistence mechanism, thus not flushing automatically but leave the task to the DAOs. Lazy loading is then the main advantage.

thanks

frantuma