From my reading so far, I have not been eble to determine if its possible to have an object enabled for lazy loading, but prevent transparent persistence.

My real issue is, I would like to keep the functionality of lazy loading, for when I pass my objects to the UI. However, it might be too easy/tempting for my UI guys to manipulate the object on the JSP page, which from my understanding would transparently persist to the database when the session is eventually closed by the servlet filter.

If my data access layer could return "locked" objects that can still be lazy loaded but not updated, I think it would be a real win win situation.

TIA
David

You should give your user interface layer exactly the graph of objects it needs and not use magic lazy loading and unclear transaction boundaries (even if it would be available).

Well probably you should just adjust the visibilitiy of your get/set methods accordingly ...

Changing the visibility would work to prevent the UI from setting values, but are required for the business layer.

So does this mean that lazy loading should never be used at the presentation layer?

Well, I'd probably use lazy loading in small two-tiered web applications with a ThreadLocal and Interceptor pattern for Session and Transaction management. In all other cases I'd return the correct subgraph from my service layer, even consider DTOs and/or automatic assemblers.

This is a question of application design and there are many best practices but no "you are right I am wrong"-kind of answers for everything.

I really recommend Hibernate in Action or one of our trainings for architectural questions that go beyond regular Hibernate usage. If you search the forum you'll find many discussions, but this stuff is much easier to communicate with a full example (as in the book) or in person.

Thanks, I actually have my Hibernate in Action book right beside me.

Things like access controll to methods is really something your code should be doing IMHO. Either use method visibility (package or something), educate your co-programmers, use some static code checking tools, whatever.