This question was partially covered by the "locking objects" thread earlier, but I thought I'd expand on it a bit.

What I'd like to be able to do, is to return a Hibernate-retrieved object from my facade, and for this object to be read-only to the facade client. By this, I mean that any changes which the client makes to the object will not be persisted to the database. Only when the object is passed back to the facade in a later method, will the changes be persisted (within a transaction controlled by the facade).

The simplest solution would be to detach the object from the session, allow the client to change it, then reattach to a new session, but unfortunately I need to be able to lazily fetch collections and the like, so that option's out.

Essentially, I need to "buffer up" all changes the client makes, so that I can be sure they won't be flushed until the DAO wants them to be. I could set the flush mode of the session to FlushMode.NEVER, but that won't stop a determined client from just flushing manually, and making the whole effort pointless.

I suspect that I'm on to a loser here, but I thought I'd throw this one out there and see if anything comes of it :)

So, you can't accept a FlushMode, you can't accept Detached Objects, and so on. If you rule out every feature because of some minor problem (both are not problems in practice, mind you) you discovered, you will lose.

Christian, it's not a case of "can't accept". I can, and already have, accepted those, and I'm using them. I'm just trying to find a better solution. What's so bad about that?

I'd appreciate it if you could explain why the FlushMode and detached object problems are not problems, because they seem rather intractable to me. The former is vulnerable to clients manually flushing, and the latter makes it cumbersome to navigate deep object graphs.

If you find a new/better solution, you are welcome. Your statements like "can't lazy load" make me believe that you might first have to spent more time with the existing concepts.

OK, we're getting there.

*** you might first have to spent more time with the existing concepts

Clearly, that's why I'm asking. You're implying that I can lazily fetch my object graph even after detaching from the session. This would be great, but I'm not aware of how to do it. Please enlighten me.

Sure, just leave the Session open or reattach. What did you expect? Magic transactions going on behind the scenes? That would be really bad for your unit of work plan.

As I explained, by leaving the session open (which what I'm doing just now), it leaves the persisted data open to modification by the client, which is outside the scope of the transaction. It's the very unit-of-work pattern that would suffer in this case. I need to stop Hibernate from flushing those changes until the thread is back within the scope of a transactional component.

Is there perhaps some setting regarding the dirty-checking of the object, where I tell the session not to check the object for changes until I tell it to? That would be rather like keeping the lazy-fetching of an open session, with the safety of a detached object. That might give a nice workaround.

FlushMode.NEVER