In your experience would it make sense to mark the HibernateSession object as being read-only at the end of your Controller's execution in MVC design pattern.

So that the View can only read data with Hibernate to do its work. When I say mark read-only I mean no new write methods can be called on the session after this point. This does not affect any transactional flushing that might not have taken place yet, since those write's were . This flag would also need to be able to be cleared, so that another request in the same session could continue to work later.

This is just to ensure that the View code is never able to modify application data and emit warnings/errors if it even tried.

Does what I'm getting at make sense to you ?

Does Hibernate have any code to enforce this policy ?

Thanks

Just wrapp hibernate session with stuff similar to DAO and " another request in the same session could continue to work later " must never happen, open and close hibernate session in filter or in "controler", requests work concurrently.

I thought HibernateSession's can be retained across multiple-requests, this is an extension to the Open Session in View, where the view can use the session to construct the response but the session has not finished yet (not in the filter run for of the THAT request/response anyhow).

This stuff is related to concurrency control, if you want to reuse hibernate session and persistent object instances for many HTTP requests ( stuff is stored in HTTP session) then you must synchronize stuff and manage concurrency control yourself (think many times before to do it in web application).
"Open Session in View" maps hibernate session to thread/request and closes hibernate session after response is send, it makes lazy loading work in view, there is nothing more or less in this pattern.